Red Hat Bugzilla – Bug 141681
IOGEAR USB PDA/Serial Adapter output driver locks up using ttyUSBx.
Last modified: 2015-01-04 17:13:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
I installed an IOGEAR USB PDA/Serial Adapter on my Toshiba Satellite
2800 laptop, running Fedora Core 3 Release Linux with the kernel
updates 2.6.9-1.681. These (two adapters) where installed once
directly into the USB ports of the laptop and once indirectly using a
ProConnect USB 4-port hub, and no difference in behaviour was observed.
I started a user level application that modifies the termios settings
for ports /dev/ttyUSB0 and /dev/ttyUSB1 and it works fine as long as
the application resets the original port parameters, closes the
channels and exits normally.
If on the other hand the application starts and it is killed (^C) in
such a manner that it simply dies without reseting the ports and
closing the channels; the USB Device driver enter (at times) blocks
its output in a manner that it delivers incoming data (reads) but not
outbound data (writes).
At that point starting (in an attempt to recover the operation of the
port) minicom, /dev/agetty, stty etc. on the locked up port results in
an application lockout (needs to be killed with kill -KILL).
The only way to (I found) to recover from this failure is to pull out
the USB adapter that is failing and re-insert it into the USB port.
After that the driver is initialized correctly and functions
flawlessly until the next application abort.
The kernel logs issue at that time the following warning
WARNING: Kernel Errors Present
usb 1-2.3: pl2303_write_bulk_callback - failed resubmitting write
urb, error -1...: 8 Time(s).
Version-Release number of selected component (if applicable):
Defora Core Release 3, kernel-2.6.9-1.681_FC3.
Steps to Reproduce:
1. Start an application that switches switches to RAW and connects via
NULL modem cable to another computer using /dev/ttyUSB0 or /dev/ttyUSB1.
2. Setup CLOCAL and -CLOCAL to switch between 3-wire and full MODEM
hardware control handshake (I do this via termios method in my
3. Start a communication session at 9600,N,8,1 that echos (via write)
all incoming (via read) data at typing rates. Observe that all
4. While the application is in CLOCAL kill it (with no signal
interceptor); or while the application is in -CLOCAL kill it (with no
5. Restart the application as per step 1-3, after a number of kills,
the application will receive the incoming bytes but will fail to echo
6. At times the application may echo data all at once just before it dies.
Actual Results: The output (write) blocks.
Expected Results: The application that opens a /dev/ttyUSBx device
should be able to set up the interface via open for RW, no delay, no
tty and then set up for a CLOCAL and write out data.
I tested the remote computer by keeping all serial port lines attached
but shorted pins 2 to 3. The remote computer does not have a problem
sending and receiving data.
If I remove and re-insert the USB adapters the problem goes away (for
The behaviour of one /dev/ttyUSBx is independent and not affected by
the behaviour of another /dev/ttyUSBy on the same computer.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.