Bug 141681 - IOGEAR USB PDA/Serial Adapter output driver locks up using ttyUSBx.
IOGEAR USB PDA/Serial Adapter output driver locks up using ttyUSBx.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 16:46 EST by Avygdor Moise
Modified: 2015-01-04 17:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 20:06:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Avygdor Moise 2004-12-02 16:46:09 EST
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.
Comment 1 Dave Jones 2005-07-15 13:35:22 EDT
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'.

Thank you.
Comment 2 Dave Jones 2005-10-02 20:06:38 EDT
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.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.