From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: When trying to use cdrecord with an USB CD-writer, I get first a message about missed interrupts and a minute later, a kernel panic. Version-Release number of selected component (if applicable): kernel-2.4.18-14 How reproducible: Always Steps to Reproduce: 1.Attach the USB CD-writer (4x). 2. cdrecord dev=0,0,0 image.img (lowering the writing speed does not help). Actual Results: Stack c255b660 00000202 00000000 c0135058 b8f6cf45 6b203534 df9a0200 e084af7c 6b203534 00000000 00000000 00000000 c24fc6c0 00000000 00000000 00000000 df9a0200 df9a0200 00000000 df8eba20 df9a0200 e084a1d1 df9a0200 00000000 Call Trace: [<c0135058>] kfree [kernel] 0x38 (0xc0347e6c)) [<e084af7c>] usb_destroy_configuration [usbcore] 0x1fc (oxc0347e7c)) [<e0860ce4>] usb_free_dev_R447e67de [usbcore] 0x37 (0x0347eb4)) [<e0860ce4>] process_usb [usb-uhci] 0x164 (0x0347ec0)) [<e0860e77>] uhci_interrupt [usb-uhci] 0x97 (0xc0347eec)) [<c010a684>] handle_IRQ_event [kernel] 0x45 (0xc0347f18)) [<c010a824>] do_IRQ [kernel] 0x84 (0xc0347f38)) [<c010cdf8>] call_do_IRQ [kernel] 0x5 (0xc0347f58)) [<c0110018>] pci_conf1_read [kernel] 0x8 (0xc0347f78)) [<c0114c32>] apm_bios_call_simple [kernel] 0x62 (0xc0347f84)) [<c0114c19>] apm_bios_call_simple [kernel] 0x49 (0xc0347f90)) [<c0114d77>] apm_do_idle [kernel] 0x27 (0xc0347fac)) [<c0114ed2>] apm_cpu_idle [kernel] 0xc2 (0xc0347fc4)) [<c0107040>] default_idle [kernel] 0x0 (0xc0347fd0)) [<c0105000>] stext [kernel] 0x0 (0x0347fd4)) [<c01070d4>] cpu_idle [kernel] 0x24 (0xc0347fdc)) Code: 8b 41 0c 29 c6 89 f0 f7 73 f7 73 18 89 c6 8b 41 14 89 44 b1 18 8b <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Expected Results: Well, I should get my CD burnt. Additional info: This happens with 7.3 kernel on a desktop machine as well. The CD Writer is: Vendor=0x3ee, ProdID=0000 Rev=2.45 Manufacturer=MITSUMI Electric Co.,Ltd. Product=USB CD-R/RW Drive The interrupt message printed before crash is: usb-uhci.c: interrupt, status 3, frame# 1795.
If I interrupt cdrecord before the kernel panic but after the interrupt message, I get the kernel panic anyway. This time I got it with following stack: update_process_times, run_timer_list, bh_action, tasklet_hi_action, do_softirq, do_IRQ, call_do_IRQ, pci_conf1_read, default_idle, apm_cpu_idle, default_idle, stext, cpu_idle
Does the 2.4.20-18.8 work for you?
The symptoms have changed: I do not get kernel panic registered anywhere but the box still hangs. It seems to take several seconds longer before it does but it still does, and does it hard.
I should add that the box has been upgraded to RH9 since then.
I am assuming you run it from text console, and not X11 window, because this is how we can see messages. When it hangs, does <CapsLock> switch LEDs? If yes, please, try to hit <Alt><SysRq>"T" and let me know if stack trace is dumped. If keyboard is dead, please add "nmi_watchdog=1" to your grub.conf arguments where root=LABEL=/ sits, and retry the test. It might convert a hang to oops, which may be possible to debug. A blind hang is hopeless.
Pawel, I would you to try Fedora's kernel 2.4.22-1.2140 (or later). It has a fix for such problem. If you're still on RHL 9, just install the rpm, it is pretty much compatible (minus external modules). Please let me know the status.
I am still on rh9 but I think I could try the new kernel during the weekend.
It does not hang any more - which is a great success! - but the recorder still does not function. Info about interrupts is still being printed (I do not know whether it is relevant or not but I thought I would mention it). usb-uhci.c: interrupt, status 3, frame# 1156 usb-uhci.c: interrupt, status 3, frame# 1144 System info: 2.4.22-1.2140.nptlsmp #1 SMP Tue Jan 6 20:11:24 EST 2004 i686 i686 i386 GNU/Linux
Apparently, needs an override in unusual_devs.h. What a pain. Please attach /proc/bus/usb/devices and /proc/scsi/usb-storage-*/*
Hardware Data: Mitsume USB, Model CR4824TU, external USB CD-R/RW drive. $ cat /proc/scsi/usb-storage-0/1 Host scsi1: usb-storage Vendor: EXATEL , Inc. Product: I-BEAD Multi Player Serial Number: 012345678901 Protocol: Transparent SCSI Transport: Bulk GUID: 066f80080000012345678901 Attached: No $ cat /proc/scsi/usb-storage-1/2 Host scsi2: usb-storage Vendor: MITSUMI Electric Co.,Ltd. Product: USB CD-R/RW Drive Serial Number: None Protocol: 8020i Transport: Control/Bulk/Interrupt GUID: 03ee00000000000000000000 Attached: Yes ]$ cat /proc/bus/usb/devices T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=105/900 us (12%), #Int= 2, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=ff40 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c00c Rev=21.10 S: Manufacturer=Logitech S: Product=USB Optical Mouse C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03ee ProdID=0000 Rev= 2.45 S: Manufacturer=MITSUMI Electric Co.,Ltd. S: Product=USB CD-R/RW Drive C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=02 Prot=00 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=1ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=ff60 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=ff80 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms (I could not find a way to attach a file. I am formally logged in, when I try to attach a file I get asked to give the password and I get "you did not attach a thing" message on the following page).
Something is very fishy. The Mitsumi with 8020 protocol is one of the oldest, well understood devices. It must just work. At this point, I am willing to entertain wild theories, such as BIOS interfering by emulating PS/2. Is it possible to plug the thing into the another UHCI? Two connectors together are fed from the same controllers, but there must be a header or a front connector... Another good thing to try would be to run a stock 2.4 kernel or 2.6 kernel and see if one of them works.
Regerding the USB connector, I connected the cd-writer to entirely different computer (self-assembled 1CPU AMD) and the effect is identical. I have yet to try stock kernels.
I have tried it with 2.6.3 kernel and the cdrecord just stops - but the kernel panic is gone. I must say I do not use this device any more - it is just too old and to slow.
I'm afraid it's useless to pretend I'm working on this bug, so closing. Sorry. Please feel free to refile against FC2 with 2.6 kernel if you feel like spending some time testing it after all.