From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

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).

Thanks
Avygdor Moise

Version-Release number of selected component (if applicable):
Defora Core Release 3, kernel-2.6.9-1.681_FC3.

How reproducible:
Always

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
application).
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
characters echo.
4. While the application is in CLOCAL kill it (with no signal
interceptor); or while the application is in -CLOCAL kill it (with no
signal interceptor).
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
them.
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.

Additional info:

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
a while).

The behaviour of one /dev/ttyUSBx is independent and not affected by
the behaviour of another /dev/ttyUSBy on the same computer.