From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
Description of problem:
When I plug in the Keyspan 19Qi USB serial adapter, it doesn't work, and causes
a kernel Oops.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Plug a Keyspan 19Qi USB serisl adapter into a USB port
Actual Results: Kernel oops
Expected Results: Should work as a serial port
Created attachment 81505 [details]
log messages showing Keyspan probing and Oops
Please give me /proc/version of the failing kernel,
and also try 2.4.18-17.8.0 (available from updates area at ftp.redhat.com).
Created attachment 83944 [details]
Created attachment 83945 [details]
log messages incl. oops from 2.4.18-17.8.0
I get the same "oops" with my Keyspan USA-19QW. I have gotten the same oops with
the stock 8.0 kernel (2.4.18-14) that I compiled myself to include the firmware,
as well as 2.4.18-8.0-17, and the just release -18. Since this has worked on
other distros in the past I did some experimentation. I compiled the kernel.org
2.4.19 using the firmware from keyspan's site and it works fine with 8.0. Here
is where it gets interesting. If I boot to my 2.4.19 kernel or Win2K and get the
adaptor working, then reboot without powering down into the Redhat 2.4.18
kernel, the adaptor is recognized and works. If I then unplug my adaptor and
plug it back in, I get the kernel oops. This tells me that one of the Redhat
patches to the kernel doesn't like the keyspan firmware or vice-versa.
BTW - additional information on my bug is at
kmp, I don't think the issue is an incompatability with the Keyspan firmware,
though it is related to the firmware loading process. I think it's caused by
the Cypress chip in the Keyspan attempting what Cypress calls "renumeration":
when the device is initially detected with no firmware, it shows up with one ID.
The driver detects this, loads the firmware, and tells the device to go. The
device signals a USB disconnect, just as if it had been physically unplugged,
then an insertion. This is to force the host to enumerate the bus again, at
which point it finds the same device with a different ID.
Based on the log messages, I think the Red Hat kernel is failing to deal with
the disconnect properly.
Created attachment 86628 [details]
*** Bug 74256 has been marked as a duplicate of this bug. ***
As you can see in bug 74256, this isn't unique to the 19Q. Try the stock kernel from ftp.kernel.org -
it works, but doesn't (obviously) have the Red Hat patches.
You can get Rawhide kernels to get Red Hat patches integrated.
Integrated milan >2.4.18-19 or Rawhide (should be at 2.4.20 a.t.m.)