Description of problem:
Keyspan 4-port USB-serial adapter does not function under new kernel
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot new kernel
2. Run various serial I/O programs using Keyspan device
Partial communication (lights flash, apparently writing data ok), but no read
data comes back.
Using programs and exact setup that worked under 22.214.171.124-2187_FC5
May be related to bug 211362
Created attachment 139716 [details]
lsusb -v output
I have the exact same device as Martin and have the same problem on FC6 with
kernel 2.6.18-1.2798.fc6. It was working under FC5 (although I never tried with
2.6.18-2200.fc5). This is occurring on two separate systems, a laptop that was
upgraded from FC5 and a desktop system that was a fresh install of FC6.
The problem still seems to be in 2.6.18-1.2835.fc6.
I have similar problems with ANY serial comms using the following kernels:
The serial ports worked on the initial FC5 install. All my built in serial ports
( ttyS* ) and a Keyspan USB-serial dongle appear otherwise OK, but I cant send
recieve dat via minicom, kermit, or other serial interface programs. I can open
the ports & write to them, ports all have IRQ & the interrupts increase on writes.
Note that my above comment #4 applies to 3 seperate machines, all with recent
I'm seeing a similar failure under FC-6 with a Keyspan P/N USA-19HS single port
USB->Serial adapter. Kernel version 2.6.18-1.2849.fc6
It worked under FC-3, kernel version 2.6.12-1.1381_FC3, which is the previous FC
version I had installed.
My simple test:
1. Connect adapter to USB port.
2. Jumper pins 2 and 3.
3. Open two terminal windows
4. Run at the command line of either window:
stty -F /dev/ttyUSB0 4800 cs8 raw cread clocal -parenb -cstopb -echo
5. In first window, enter:
6. In second window, enter:
echo "This is a test" > /dev/ttyUSB0
Expected esult: The echoed text should appear in the first window.
Actual result: Nothing appears in the first window.
The same test performed under FC-6 with an adapter with a Prolific PL2303
chipset works. The same test performed under FC-3 works with either of the two
The same results are observed if a null modem cable is used to connect the
USB->Serial adapter to a regular RS232 serial port on the same or different PC.
More info: I am now trying 2.6.18-1.2239.fc5... (1) When I send data to
/dev/ttyUSB2 (on my Keyspan device) it is received correctly by the other system
(a radio transceiver). So many things are working. But when the other system
sends data back, it is not received. My app. times out on the read operation.
All this works correctly on 2.6.17 kernels.
(2) The same app works correctly over /dev/ttyS0.
The problem persists for me with kernel 2.6.18-1.2849.fc6. Is there any
upstream activity regarding this issue?
Confirmed with 2.6.18-1.2849.fc6 with a Keyspan USA-HS19. Did work under FC5.
Serial port does transmit, send BREAK, etc. No data is received from the USB
Reproduced on multiple machines with different UHCI host controllers. Device
works on same systems under Windows and confirmed functional on a MacBook Pro
under OS X.
Can Jeffrey, Dave, or Martin provide me a single kernel version which worked?
So far it's too nebulous for me to run diff.
I'm not counting Josh because his problem is obviously different, he needs
a separate bug.
Sure. The latest version that works for me is
Linux version 2.6.17-1.2187_FC5 (firstname.lastname@example.org) (gcc
version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 Mon Sep 11 01:17:06 EDT 2006
As far as I can tell, if it's 2.6.17.*, it's OK. If it's 2.6.18.*, it's NOK.
Let me know if there is more that I can do. This is really a show stopper in my
I've had the same issue with my keyspan USB device not properly functioning.
The linux kernel bugzilla mentions a bug which may be related or the same.
Someone just posted a patch. Can somebody try it? I also really need to have
this fixed under FC5, and would rather not go back to a .17 kernel. The last
one that works for me is 2.6.17-1.2139_FC5smp, though the next one I tried was a
The bug is 7544: http://bugzilla.kernel.org/show_bug.cgi?id=7544
According to the kernel bug (7544), it looks like it was patched against
2.6.20.rc2. Any idea when we might see this in the Fedora kernels (assuming it
works)? I'd like to resume using linux for router configuration instead of
booting into The Other OS.
The problem is gone for me now in 2.6.20-1.2300.fc5.
Ditto, device also works for me under SMP (2.6.20-1.2300.fc5smp)
Big thanks for keeping FC5 current