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 /var/log/message endlessly: kernel: NETDEV WATCHDOG: eth0: transmit timed out kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x1E1 Version-Release number of selected component (if applicable): Kernel 2.6.18-1.2868.fc6 This is a new installation and everything is updated. How reproducible: Always Steps to Reproduce: 1.Boot with "acpi=noirq" 2.Suspend to RAM with pm-suspend 3.Resume by pressing the power button Actual results: Successful resumption, except for lost network and USB ports. I haven't tested the modem or parallel port. Expected results: The machine to return to its state prior to suspension. Additional info: (1) This is on an Emachines T5216: CPU: Dual Core Pentium D ATIIXP: chipset revision 128 512MB RAM (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 (dmesg.resume.txt). (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 wrong IRQ. (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 at all?
It's not exactly current, but the same problem occurs with kernel 2.6.20-1.2944.fc6. 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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.