Bug 391801 - Massive numbers of wakeups (50K) reported after reboot
Massive numbers of wakeups (50K) reported after reboot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-20 05:09 EST by Mark Bailey
Modified: 2009-01-09 02:28 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:28:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lsmod (3.34 KB, application/octet-stream)
2008-03-02 05:34 EST, Mark Bailey
no flags Details
dmesg (29.59 KB, application/octet-stream)
2008-03-02 05:35 EST, Mark Bailey
no flags Details
powertop high values (1.04 KB, application/octet-stream)
2008-03-02 05:35 EST, Mark Bailey
no flags Details
sudo powertop --dump (3.03 KB, text/plain)
2008-05-25 14:32 EDT, Peter F. Patel-Schneider
no flags Details
top (8.31 KB, text/plain)
2008-05-25 14:33 EDT, Peter F. Patel-Schneider
no flags Details

  None (edit)
Description Mark Bailey 2007-11-20 05:09:34 EST
Description of problem:
powertop reporting massive number of wakeups ~50K after reboot.

Starting from a powered down state and booting into fedora 8 
(2.6.23.1-49.fc8), powertop reports normal range of wakeups. 
After rebooting (no powerdown) powertop reports massive number
of wakeups (~50,000) that aren't being caused by applications.

Interestingly, doing a suspend to ram and waking up, restores
the powertop readings to the normal range. Full powerdown and
boot also. Booting with noapic also stops the phantom wakeups
but breaks other things such as suspend to ram. 

Not sure if it's related but irqbalance shows as failed in 
the shutdown sequence.

How reproducible:
Allways.

Steps to Reproduce:
1. Boot from power off
2. Check powertop
3. Reboot
4. Check powertop

Additional info:
Lenovo C1000 N100 laptop (Intel T5500 core2) 

[root@localhost ~]# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML 
Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition 
Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 
(rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI 
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI 
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge 
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE 
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 
02)
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network 
Connection (rev 02)
05:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
05:04.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01)
05:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
05:06.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 
SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
05:06.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)
05:06.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter 
(rev 0a)
05:06.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)
Comment 1 Christopher Brown 2008-02-13 18:19:24 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few weeks if there is no additional information lodged.
Comment 2 Mark Bailey 2008-02-14 05:35:06 EST
Hi,
No change in 2.6.23.15-137.fc8, same symptoms.
What additional information/actions can I provide that might help?
Thanks,
Mark
Comment 3 Christopher Brown 2008-02-14 14:49:16 EST
Could you attach the following as text/plain individual attachments to this bug:

dmesg > dmesg.out
lsmod > lsmod.out

If you can cut and paste the powertop output as well that might be helpful.

Cheers
Chris
Comment 4 Mark Bailey 2008-03-02 05:34:53 EST
Created attachment 296501 [details]
lsmod
Comment 5 Mark Bailey 2008-03-02 05:35:22 EST
Created attachment 296502 [details]
dmesg
Comment 6 Mark Bailey 2008-03-02 05:35:52 EST
Created attachment 296503 [details]
powertop high values
Comment 7 Peter F. Patel-Schneider 2008-05-25 14:29:52 EDT
I am also experiencing this problem.  The number of wakeups is somewhat lower,
8K to 20K per second, but there appears to be no reason for them.  I have seen
reports of this problem on other distributions, notably Ubuntu.  I am running
current Fedora 9 on a Thinkpad T60p.

The problem does not appear to be a bug in powertop, as sensors-applet is
reporting high temperatures, and power manager is reporting high power
consumption.  The problem is not constant (and I did not experience it at all in
recent F8 versions).

name -a
Linux idefix.research.bell-labs.com 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13
05:38:53 EDT 2008 i686 i686 i386 GNU/Linux

I'll attach powertop and top output.

Comment 8 Peter F. Patel-Schneider 2008-05-25 14:32:43 EDT
Created attachment 306625 [details]
sudo powertop --dump
Comment 9 Peter F. Patel-Schneider 2008-05-25 14:33:08 EDT
Created attachment 306626 [details]
top
Comment 10 Peter F. Patel-Schneider 2008-06-12 05:40:44 EDT
Hi:

This bug is still present in the current version of F9,
 2.6.25.4-30.fc9.i686 

There is some discussion on it (interspersed with discussion of the rescheduling
interrupts behaviour) on 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/145377 

The bug appears to be related to particular hardware (I have a T60p), my guess
being either the wireless card (I have a 3945) or the cardbus bridge (because
that misbehaves in other ways).

Anyway, my question is whether there are things that I can do to help track down
the source of the problem.   For example, is there a tool that can analyse DMA
activity (because my guess is that the wakeups are not interrupts, but instead
are related to DMA).

Peter F. Patel-Schneider
Comment 11 Rene Wagner 2008-07-21 17:56:43 EDT
Rebuilding the kernel with yenta_socket built as a module and adding yenta_socket 
to the modprobe blacklist works around the problem for me.

I've filed Bug #456173 requesting the kernel config to be changed so that the 
rebuilding step will not be necessary any longer.

Rene
Comment 12 Bug Zapper 2008-11-26 03:36:13 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 13 Peter F. Patel-Schneider 2008-12-01 18:23:01 EST
I haven't seen this for quite some time.  I expect that the problem has gone away for some reason or other.
Comment 14 Bug Zapper 2009-01-09 02:28:07 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.