Description of problem: Since upgrading to Fedora 9 neither the DVD drives nor hotplugging of USB pen drives work. This happens after the message "irq23: nobody cared" message. After this message: Disabling IRQ #23 ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout) ata7.00: status: { DRDY } ata7: soft resetting link ata7: nv_mode_filter: 0x701f&0x701f->0x701f, BIOS=0x7000 (0xc0000000) ACPI=0x701f (60:600:0x13) ata7.00: configured for UDMA/33 ata7: EH complete ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata7.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout) ata7.00: status: { DRDY } ata7: soft resetting link ata7: nv_mode_filter: 0x701f&0x701f->0x701f, BIOS=0x7000 (0xc0000000) ACPI=0x701f (60:600:0x13) ata7.00: configured for UDMA/33 ata7: EH complete ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata6.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout) ata6.00: status: { DRDY } ata6: soft resetting link ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: configured for UDMA/66 ata6: EH complete messages are shown over and over again. ata6 and ata7 are the DVD drives. See attached message log for details. Version-Release number of selected component (if applicable): 2.6.25.3-18.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot the kernel 2. Wait up to 5 minutes 3. Actual results: An error is shown, DVD drives cease to work, USB pen drives do not generate events. Expected results: DVD drives and plugging in usb pen drives work, as it did with Fedora 8. Additional info: Adding irqpoll does not change the behaviour. Devices attached and active at boot time, like my mice, stay active.
Created attachment 306352 [details] kernel messages with and without irqpoll
Created attachment 306413 [details] Kernel messages on Fedora 9 with kernel 2.6.24.7-92.fc8 I am currently running 2.6.24.7-92.fc8 and the described behavior does not occur. That means that USB pen drives get recognized when plugged in and I can play DVD's. I attached the kernel messages with the 2.6.24.7-92.fc8 kernel. I also noticed that the LED of my USB drives stays dark when plugged in into the computer when running kernel-2.6.25.3-18.fc9.x86_64.
irqpoll will not help here. Try noirqdebug
Ah here we go... "HC died"... sounds rather bad: May 22 08:23:27 localhost kernel: ehci_hcd 0000:00:0a.1: HC died; cleaning up May 22 08:23:27 localhost kernel: usb 1-7: USB disconnect, address 4 May 22 08:23:27 localhost kernel: usb 1-9: USB disconnect, address 6 May 22 08:23:27 localhost kernel: usb 1-10: USB disconnect, address 7 May 22 08:23:33 localhost kernel: irq 23: nobody cared (try booting with the "irqpoll" option) It had registered for IRQ 23 earlier: May 22 08:18:54 localhost kernel: ehci_hcd 0000:00:0a.1: EHCI Host Controller May 22 08:18:54 localhost kernel: ehci_hcd 0000:00:0a.1: new USB bus registered, assigned bus number 1 May 22 08:18:54 localhost kernel: ehci_hcd 0000:00:0a.1: debug port 1 May 22 08:18:54 localhost kernel: ehci_hcd 0000:00:0a.1: irq 23, io mem 0xfe02e000 May 22 08:18:54 localhost kernel: ehci_hcd 0000:00:0a.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
(In reply to comment #3) > irqpoll will not help here. Try noirqdebug I am booting with noirqdebug now and it keeps my DVD drives alive for now. HC still dies however.
I think EHCI is being the victim of an interrupt flood on a shared interrupt. The "HC Halted" message is reported when the common interrupt shim for HCDs detects that the HC's state is HC_STATE_HALT. Normally, the HCD sets that when the hadware actually halts (e.g. on EHCI it's STS_HALT). But when HC is being initiated, in EHCI in particular there's a window where status is set to HC_STATE_HALT, but there's nothing especially wrong with the hardware. If a shared interrupt happens, we get the HC Halted situation. The usb_hcd_irq tries to take shared interrupts into account, but the thing is, EHCI's HCD expects the end-of-reset interrupt, and so ehci_irq() falls further than the check that returns IRQ_NONE. I'm not sure what the right fix is. Perhaps returning IRQ_NONE with a better precision would do it?
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.