Bug 447872 - DVD Drives and Hotplug do not work
DVD Drives and Hotplug do not work
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-22 04:53 EDT by Marcel Kyas
Modified: 2009-07-14 12:42 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:42:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kernel messages with and without irqpoll (201.53 KB, text/plain)
2008-05-22 04:53 EDT, Marcel Kyas
no flags Details
Kernel messages on Fedora 9 with kernel 2.6.24.7-92.fc8 (93.92 KB, text/plain)
2008-05-22 15:08 EDT, Marcel Kyas
no flags Details

  None (edit)
Description Marcel Kyas 2008-05-22 04:53:23 EDT
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.
Comment 1 Marcel Kyas 2008-05-22 04:53:23 EDT
Created attachment 306352 [details]
kernel messages with and without irqpoll
Comment 2 Marcel Kyas 2008-05-22 15:08:08 EDT
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.
Comment 3 Chuck Ebbert 2008-05-23 02:05:08 EDT
irqpoll will not help here. Try noirqdebug
Comment 4 Chuck Ebbert 2008-05-23 02:10:02 EDT
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
Comment 5 Marcel Kyas 2008-05-31 08:02:41 EDT
(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.
Comment 6 Pete Zaitcev 2008-08-13 22:10:32 EDT
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?
Comment 7 Bug Zapper 2009-06-09 21:05:13 EDT
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
Comment 8 Bug Zapper 2009-07-14 12:42:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.