Comment redémarrer ttyusb *

J'ai deux périphériques qui alimentent continuellement les données via ttyUSB0 et ttyUSB1. J'ai des scripts php qui utilisent ces données. Le problème dans lequel je me heurte est que parfois les aliments se bloquent. La meilleure façon d'avoir réparé ceci consiste à débrancher la carte BUB de l'ordinateur et à le brancher à nouveau. Cependant, je recherche un moyen d'automatiser cette action. Existe-t-il un moyen de dire à linux d'éjecter essentiellement le conseil d'administration de BUB et de le reprendre quelque peu?

J'ai le même problème que vous dans un contexte différent (j'ouvre une console série sur une boîte linux). Le lien série parfois ne répond plus et je dois débrancher physiquement le convertisseur USB-série.

Ce qui suit semble résoudre mon problème, mais pas toujours.

  1. Trouvez le pilote associé à votre appareil ttyUSBx.

    [My-pc] # cat / proc / tty / drivers

    /dev/tty /dev/tty 5 0 system:/dev/tty /dev/console /dev/console 5 1 system:console /dev/ptmx /dev/ptmx 5 2 system /dev/vc/0 /dev/vc/0 4 0 system:vtmaster rfcomm /dev/rfcomm 216 0-255 serial usbserial /dev/ttyUSB 188 0-253 serial ttyprintk /dev/ttyprintk 5 3 console serial /dev/ttyS 4 64-111 serial pty_slave /dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master unknown /dev/tty 4 1-63 console 

    Vous pouvez voir que /dev/ttyUSB utilise usbserial . Maintenant, creusez un peu plus loin:

    [My-pc] # lsmod | Grep usbserial

      usbserial 37173 1 pl2303 

    Dans mon cas, mon convertisseur USB-série est un PL1303 Prolifique. Si vous avez un adaptateur FTDI, je pense que vous devriez voir ftdi_sio au lieu de pl2303 .

  2. Décharger le conducteur

    Sudo modprobe -r pl2303 #or ou le nom qui correspond à votre configuration

    Sudo modprobe -r usbserial

  3. Re-charger le pilote

    Sudo modprobe pl2303 #or le nom qui correspond à votre configuration

  4. Relancez votre communication série

Avec la réponse de sdive, je continuais à obtenir "FATAL: Module usbserial est utilisé".

J'ai finalement résolu le problème avec quelques conseils de la réponse de LiLo ici: https://askubuntu.com/a/661/379851

Mais au lieu d'utiliser un code C, j'ai écrit un équivalent python qui trouve également le bus et le périphérique en question:

 #!/usr/bin/env python import os import sys from subprocess import Popen, PIPE import fcntl driver = sys.argv[-1] print "resetting driver:", driver USBDEVFS_RESET= 21780 try: lsusb_out = Popen("lsusb | grep -i %s"%driver, shell=True, bufsize=64, stdin=PIPE, stdout=PIPE, close_fds=True).stdout.read().strip().split() bus = lsusb_out[1] device = lsusb_out[3][:-1] f = open("/dev/bus/usb/%s/%s"%(bus, device), 'w', os.O_WRONLY) fcntl.ioctl(f, USBDEVFS_RESET, 0) except Exception, msg: print "failed to reset device:", msg 

Enregistrez-le simplement comme reset_usb.py ou quelque chose, puis exécutez-le comme ceci:

 sudo python reset_usb.py driver_name 

Où driver_name est la sortie de

 lsmod | grep usbserial 

Dans mon cas, c'était cp210x, alors je l'exécute comme ceci:

 sudo python reset_usb.py cp210x 

Voici ma réponse pour le module ftdi_sio . Les étapes sont adaptées de la réponse ci-dessus et le lien d'un commentaire dans la question initiale.

Je ne pouvais pas retirer le module:

 % sudo rmmod ftdi_sio rmmod: ERROR: Module ftdi_sio is in use % sudo modprobe -r ftdi_sio modprobe: FATAL: Module ftdi_sio is in use. 

Donc j'utilise l'astuce suivante:

 % sudo dmesg | grep ttyUSB0 [ 4.784615] usb 3-2.4: FTDI USB Serial Device converter now attached to ttyUSB0 

Ce qui a effectivement été vérifié par:

 % tree /sys/bus/usb/drivers/ftdi_sio /sys/bus/usb/drivers/ftdi_sio ├── 3-2.4:1.0 -> ../../../../devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.4/3-2.4:1.0 ├── bind ├── module -> ../../../../module/usbserial ├── uevent └── unbind 2 directories, 3 files 

Ensuite, il était facile d'enlever le module:

 # echo -n "3-2.4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind # rmmod ftdi_sio # rmmod usbserial 

Et ensuite, simplement:

 # modprobe ftdi_sio 

Ce n'est pas clair pourquoi ftdi_sio est dans une forme aussi mauvaise, peut-être encore être un bug comme dans:

Mais il semble que kernel 4.9.20 contient toujours un mauvais module ftdi_sio .