I have two devices that are continuously feeding data through ttyUSB0 and ttyUSB1. I have php scripts that are using this data. The problem I am running into is that sometimes the feed just kind of freezes. The best way I've seen to fix this is to unplug the BUB board from the computer and plug it in again. However, I am looking for a way to automate this action. Is there a way to to tell linux to essentially eject the BUB board and then somehow pick it up again?
I'm having the same problem as you but in a different context ( I open a serial console on a linux box ). The serial link sometimes becomes unresponsive and I have to physically unplug the USB-serial converter.
The below seems to solve my problem, but not always.
Find the driver associated to your ttyUSBx device.
[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
You can see that
usbserial. Now dig a little further:
[my-pc]# lsmod | grep usbserial
usbserial 37173 1 pl2303
In my case, my USB-to-serial converter is a Prolific PL2303. If you have a FTDI adapter, I think you should see
Unload the driver
sudo modprobe -r pl2303 #or the name that matches your config
sudo modprobe -r usbserial
Re-load the driver
sudo modprobe pl2303 #or the name that matches your config
Re-launch your serial communication
With sdive's answer I kept getting "FATAL: Module usbserial is in use."
I finally solved the problem with some guidance from LiLo's answer here: https://askubuntu.com/a/661/379851
But instead of using some C code, I wrote a python equivalent that also finds the bus and device in 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 device = lsusb_out[:-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
Just save this as reset_usb.py or something and then run it like this:
sudo python reset_usb.py driver_name
Where driver_name is the output from
lsmod | grep usbserial
In my case, it was cp210x, so I run it like this:
sudo python reset_usb.py cp210x
Here is my answer for the module
ftdi_sio. Steps are adapted from the above answer and the link from a comment in the original question.
I could not get the module to be removed:
% 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.
So I use the following trick:
% sudo dmesg | grep ttyUSB0 [ 4.784615] usb 3-2.4: FTDI USB Serial Device converter now attached to ttyUSB0
Which indeed was verified by:
% 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
Then it was easy to remove the module:
# echo -n "3-2.4:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind # rmmod ftdi_sio # rmmod usbserial
And then simply:
# modprobe ftdi_sio
This is not clear why ftdi_sio gets in such bad shape, maybe still be bug as in:
But it seems kernel 4.9.20 still contains bad