Description of problem: Immediately after installing the system (F9) "Suspend to Disk" worked fine. With the kernel 2.6.25-14.fc9.i686 it still works. After update kernel up to 2.6.26.3-29.fc9.i686 "Suspend to Disk" mode was broken: all data are recorded on the disc, but the power does not switche off. When I switch power on the computer resumes correctly (all data loaded and all user processes work), but a core of the CPU is loaded at 100% and 'top' shows that the processor is loaded by 2 processes: khubd and ksoftirqd/0. When I shut down the computer in such a situation, the problem with disconnecting the power supply is repeated. Version-Release number of selected component (if applicable): 2.6.26.3-29 and higher How reproducible: Every time Steps to Reproduce: 1. Start suspending from gnome-power-manager 2. Switch power off after all disk activities 3. Switch power on Actual results: 1 of the CPU cores is 100% loaded and CPU's frequency 100% (1.6GHz), 2 processes (khubd and ksoftirqd/0) are in the top of process list of utility 'top' (using ordering by CPU loading) Expected results: CPU is not overloaded, after resume has finished. Additional info: Hardware: Toshiba Satellite L40-17R [andrey@localhost modules]$ /sbin/lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Please attach your dmesg after a resume to this bug, or paste it in. Thanks, Kyle
Created attachment 320466 [details] dmesg before and after suspend There are 2 files in the zip-archive: dmesg-before-suspend.txt and dmesg-after-suspend.txt. And yet one portion of information. I switched to IceWM (it loads the system less than Gnome) and configure ACPI to hibernate the system using "acpitool -S". It still works, but keybord hanged several times. I cannot assert it exactly (it happened several times only) but I suppose it happened after I started parts of Gnome environment, such as nm-applet or PCManFM. I'll try connect to the laptop if it repeat.
I have tested my suggestion about Gnome programes: the keyboard has been blacked after several minutes after I start 'nm-applet'. One additional detail about my laptop: it contains an integrated USB Wi-Fi adapter "Realtek Semiconductor Corp. RTL8187B Wireless Adapter" and NetworkManager controls this adapter.
Yet one results of my experiments. The problem with kernel modules is reproduced under IceWM with PCManFM started but after long period in suspending only. For example when I suspend the laptop for a night. If the laptop is suspended for a short time (2 hours, for example) it resumed normaly. The problem with keybord is not reproduced when PCManFM started.
I think earlier version of the rtl8187b driver can stop hibernation - which one are you using - the vendor one or the new 2.6.26/2.6.27 community one?
I'm using community drive. And since kernel version 2.6.26.6-79 the problem is not reproduced. Thanks for attantion.
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.