|Summary:||IOGEAR USB PDA/Serial Adapter output driver locks up using ttyUSBx.|
|Product:||[Fedora] Fedora||Reporter:||Avygdor Moise <avy>|
|Component:||kernel||Assignee:||Dave Jones <davej>|
|Status:||CLOSED CANTFIX||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-10-03 00:06:38 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Avygdor Moise 2004-12-02 21:46:09 UTC
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 17:35:22 UTC
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-03 00:06:38 UTC
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.