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): How reproducible: Always 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 Additional info:
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] /proc/version
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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73556
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] Try #1
*** 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.)