Hide Forgot
Description of problem: System panics while booting up when a Holux GM-210 USB GPS Receiver is plugged into either USB port of my Dell Inspiron 8200 laptop. If the device is plugged in after the system is up. It will work for a short while before crashing. Code: 0f 0b e2 03 qf dc 25 c0 e9 77 fd ff ff 8d b4 26 00 00 00 00 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Version-Release number of selected component (if applicable): 2.4.20-9 How reproducible: Very Steps to Reproduce: 1. Plug in Holux GM-210 GPS Receiver into either USB port. 2. Boot the machine. 3. System panics. Actual results: Kernel panic. Expected results: No panic. Additional info: Contents of /var/log/messages when the device is plugged in after the system is up: Apr 14 15:31:52 SKIP-MORGAN kernel: usb.c: USB device 2 (vend/prod 0x67b/0x2303) is not claimed by any active driver. Apr 14 15:31:55 SKIP-MORGAN /etc/hotplug/usb.agent: Setup pl2303 for USB product 67b/2303/202 Apr 14 15:31:55 SKIP-MORGAN kernel: usb.c: registered new driver serial Apr 14 15:31:55 SKIP-MORGAN kernel: usbserial.c: USB Serial support registered for Generic Apr 14 15:31:55 SKIP-MORGAN kernel: usbserial.c: USB Serial Driver core v1.4 Apr 14 15:31:55 SKIP-MORGAN kernel: usbserial.c: USB Serial support registered for PL-2303 Apr 14 15:31:55 SKIP-MORGAN kernel: usbserial.c: PL-2303 converter detected Apr 14 15:31:55 SKIP-MORGAN kernel: usbserial.c: PL-2303 converter now attached to ttyUSB0 (or usb/tts/0 for devfs) Apr 14 15:31:55 SKIP-MORGAN kernel: pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.9 Apr 14 15:31:55 SKIP-MORGAN devlabel: devlabel service started/restarted This device works perfectly when the machine is booted with Windows XP or RedHat Linux 8.0
Apr 14 15:31:55 SKIP-MORGAN devlabel: devlabel service started/restarted hmmmm could you try removing the devlabel rpm? I've seen it cause havoc with serial stuff before
I removed the devlabel package (rpm -e devlabel) and the panic still occurs. There is what appears to be a stack dump on the screen. Is any of this information useful? Is it captured (or capturable) anywhere?
the important bits are function names of the backtrace, eg it'll look like [<e4cf239f>] register_sound_mixer_Rb3ad7eaa [soundcore] 0x3f (0xd6ee5e3c)) [<e4cf3900>] chains [soundcore] 0x0 (0xd6ee5e40)) and in such a case the only important bits are "register_sound_mixer" and "chains". While there are several options to capture this, a pen and a piece of paper sometimes is just easiest given that's only a few words to write down.
Here's what's left on the screen. I can't tell if there's more scrolled off the top... uhci_clean_transfer delete_desc delete_qh flush_to_ldisc __run_task_queue tqueue_bh bh_action tasklet_hi_action do_softirq do_IRQ apm_cpu_idle call_do_IRQ apm_cpu_idle default_idle apm_cpu_idle apm_cpu_idle default_idle cpu_idle stext
GPS is a USB serial, basically. I'll take it from here. Does the 2.4.20-18 errata work?
Sorry it took so long to answer but I downgraded the machine to 8.0. I've reinstalled 9.0 and both 2.4.20-8 and 2.4.20-18.9 still panic during bootup. I believe the stack dumps are the same as I reported previously. Since I now have both 8.0 and 9.0 installed, it shouldn't be so long between questions and answers.
Also see Bug 88072 - appears to be the same problem.
I encountered a similar panic with the kl5kusb105 module used for my PalmConnect USB<->Serial converter. The system will panic every time on boot if the converter is attached. System boots fine if converter is disconnected. errors from console: Code 0f:0b:e2:03:9f:d6:25:c0:e9:77:fd:ff:ff:8d:b4:26:00:00:00:00 <0>kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing. If I boot into single user mode, the last entries in the messages log before the reboot refer to the kl5k105usb module.
See also bug 90442 (don't dup, please)
So, did anyone try 2.4.22-1.2140 yet? I'm pretty sure I fixed this. If you're stuck with RHL 9, just install the above with rpm -i, kernels are relatively compatible between Fedora and RHL 9.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/