Red Hat Bugzilla – Bug 220272
Network and USB devices unavailable after S3 resume; acpi irq routing problem
Last modified: 2008-05-06 13:12:44 EDT
Description of problem:
After resuming from pm-suspend, the network (eth0) is unavailable and can't be
brought back except by rebooting. Also USB ports (flash drive, sd card, cf
card) are unavailable. Attempting to reach the network produces this in
kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x1E1
Version-Release number of selected component (if applicable):
This is a new installation and everything is updated.
Steps to Reproduce:
1.Boot with "acpi=noirq"
2.Suspend to RAM with pm-suspend
3.Resume by pressing the power button
Successful resumption, except for lost network and USB ports. I haven't tested
the modem or parallel port.
The machine to return to its state prior to suspension.
(1) This is on an Emachines T5216:
CPU: Dual Core Pentium D
ATIIXP: chipset revision 128
(2) Kernel 2.6.18-1.2868.fc6 (like 2798) requires acpi=noirq for the cd/dvi
drive (/dev/hdc) to work. Without it the kernel reports "hdc: lost interrupt".
Also the system hangs before entering S3 suspension without acpi=noirq.
Kernel 2.6.18-1.2849.fc6 would not boot with acpi=noirq.
(3) I've attached the output of lspci -v (lspci.txt), dmesg imediately after
booting (demesg.txt) and dmesg after then suspending and resuming
(4) Things that might be relevant in dmesg.txt:
BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor)
PCI BIOS Bug: MCFG area at e0000000 is not E820-reserved
The troublesome devices all seem to be using irq 11:
ehci_hcd 0000:00:13.2: irq 11, io mem 0x30206000
ohci_hcd 0000:00:13.0: irq 11, io mem 0x30204000
ohci_hcd 0000:00:13.1: irq 11, io mem 0x30205000
eth0: RealTek RTL8139 at 0xdc8ac000, 00:16:76:d6:27:f3, IRQ 11
Also in dmesg after resuming:
ohci_hcd 0000:00:13.0: Unlink after no-IRQ? Controller is probably using the
(5) I've checked the states of these devices in sysfs after resuming, and all
seem to be resumed (state 0).
(6) I added ehci_hcd, ohci_hcd, and uhci_hcd to SUSPEND_MODULES in
/etc/pm/config, but this doesn't seem to have had any effect. They are
"blacklisted-modules" in suspend2.
Created attachment 144067 [details]
dmesg after booting
Created attachment 144068 [details]
dmesg after resuming
Created attachment 144069 [details]
output of lspci -v
Sorry for the really slow response.
Have you been able to try a newer kernel/Fedora release? If so, has that helped
It's not exactly current, but the same problem occurs with kernel
Other than this one problem that prevents suspending/hibernating, this
installation of fc6 has worked flawlessly. It's a little difficult for me to
update because this is on the machine my wife uses during the week, about 60
miles from home. I can maintain most things via ssh, but have to be a little
careful about doing things that might hand her machine.
That said, if there is anything I can do that would be helpful to you, let me
know, and I can arrange to spend some quality time with my wife's computer.
Thanks very much.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.