Bug 466621 - Power does not switch of after suspend to disk and khubd and ksoftirqd/0 loads CPU after resume
Power does not switch of after suspend to disk and khubd and ksoftirqd/0 load...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-11 10:21 EDT by Andrey V. Henneberg
Modified: 2009-07-14 10:23 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:23:07 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)
dmesg before and after suspend (19.91 KB, application/zip)
2008-10-15 13:51 EDT, Andrey V. Henneberg
no flags Details

  None (edit)
Description Andrey V. Henneberg 2008-10-11 10:21:50 EDT
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)
Comment 1 Kyle McMartin 2008-10-15 12:26:15 EDT
Please attach your dmesg after a resume to this bug, or paste it in.

Thanks, Kyle
Comment 2 Andrey V. Henneberg 2008-10-15 13:51:32 EDT
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.
Comment 3 Andrey V. Henneberg 2008-10-15 14:40:26 EDT
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.
Comment 4 Andrey V. Henneberg 2008-10-18 03:09:33 EDT
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.
Comment 5 Hin-Tak Leung 2008-10-31 19:57:57 EDT
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?
Comment 6 Andrey V. Henneberg 2008-11-15 13:09:01 EST
I'm using community drive. And since kernel version 2.6.26.6-79 the problem is not reproduced.

Thanks for attantion.
Comment 7 Bug Zapper 2009-06-09 22:56: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 10:23:07 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.