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.
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
.
Décharger le conducteur
Sudo modprobe -r pl2303 #or ou le nom qui correspond à votre configuration
Sudo modprobe -r usbserial
Re-charger le pilote
Sudo modprobe pl2303 #or le nom qui correspond à votre configuration
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
.