Bug 454954 - kacpid and kacpi_notify consuming 80 percent cpu after resume
kacpid and kacpi_notify consuming 80 percent cpu after resume
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-10 21:06 EDT by W.C. Epperson
Modified: 2009-12-18 01:14 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:14:36 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)

  None (edit)
Description W.C. Epperson 2008-07-10 21:06:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080702 Fedora/2.0.0.15-1.fc8 Firefox/2.0.0.15

Description of problem:
Beginning with the update from 2.6.24.7-92 to 2.6.25.4-10, after resuming from suspend or hibernate, kacpid and kacpi_notify begin consuming about 80% of the cpu. Without re-nicing both to 19, the system locks up after 5-10 minutes:  cannot use mouse or alt-tab between windows, nor launch an alternate console.  With renice, the system remains usable, barely, but often locks up after some time.

This is a Dell Latitude D600, 1.4GHz processor, 

Version-Release number of selected component (if applicable):
2.6.25.9-40.fc8.i686

How reproducible:
Always


Steps to Reproduce:
1. Boot from 2.6.25 kernel
2. Suspend or hibernate
3. Resume

Actual Results:
kacpid and kacpi_notify begin consuming 80% cpu

Expected Results:
Normal cpu usage by these items should be an order of magnitude lower.

Additional info:
Output from top:  
 top - 21:05:01 up  2:15,  3 users,  load average: 1.42, 1.49, 1.54
Tasks: 144 total,   6 running, 138 sleeping,   0 stopped,   0 zombie
Cpu(s):  4.6%us, 85.6%sy,  0.0%ni,  8.7%id,  0.0%wa,  1.1%hi,  0.0%si,  0.0%st
Mem:   1294660k total,   547544k used,   747116k free,    11324k buffers
Swap:  2031608k total,        0k used,  2031608k free,   240468k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
   61 root      39  19     0    0    0 R 39.9  0.0  11:22.92 kacpid             
   62 root      39  19     0    0    0 S 39.2  0.0  11:18.15 kacpi_notify
Comment 1 W.C. Epperson 2008-07-11 15:46:44 EDT
Also see 373041, which relates to the same kernel update and appears acpi related.
Comment 2 Kyle McMartin 2008-07-12 13:41:26 EDT
Please try the rpms I scratch built here with CONFIG_ACPI_SYSFS_POWER turned off
and let me know if it fixes the issues you've seen:
http://koji.fedoraproject.org/koji/taskinfo?taskID=710780

cheers, Kyle
Comment 3 W.C. Epperson 2008-07-12 15:16:26 EDT
Kyle, these are tagged as FC9.  Would you consider them reasonably safe on an
otherwise Fedora 8 system?  If so, I take it that I should download and rpm -Uvh
the following:
kernel-2.6.25.10-91.fc9.i686.rpm
kernel-PAE-2.6.25.10-91.fc9.i686.rpm
kernel-PAE-debuginfo-2.6.25.10-91.fc9.i686.rpm
kernel-PAE-devel-2.6.25.10-91.fc9.i686.rpm
kernel-PAEdebug-2.6.25.10-91.fc9.i686.rpm
kernel-PAEdebug-debuginfo-2.6.25.10-91.fc9.i686.rpm
kernel-PAEdebug-devel-2.6.25.10-91.fc9.i686.rpm
kernel-debug-2.6.25.10-91.fc9.i686.rpm
kernel-debug-debuginfo-2.6.25.10-91.fc9.i686.rpm
kernel-debug-devel-2.6.25.10-91.fc9.i686.rpm
kernel-debuginfo-2.6.25.10-91.fc9.i686.rpm
kernel-debuginfo-common-2.6.25.10-91.fc9.i686.rpm
kernel-devel-2.6.25.10-91.fc9.i686.rpm

Am I on track here?  I'm an RHCT, but hardly a kernel expert.  Will rsync to
another box first so I can recover if necessary.  This is my primary laptop.
Comment 4 W.C. Epperson 2008-07-12 18:43:17 EDT
Oh, duh.  Obviously I don't need the PAE items on a ~1.25Gb system.  I'll make
sure I can roll back, and give it a try tomorrow.
Comment 5 W.C. Epperson 2008-07-12 21:56:35 EDT
After seeing the note from Eric in bug 373041, I gave Kyle's kernel and
kernel-dev a try with --nodeps.  Wrecked the system.  Looks like this kernel
won't work with the lvm from Fedora 8, fails on switchroot after grousing about
not finding /dev/VolGroup00/LogVol01.

Will be restoring tomorrow by booting rescue to pull my rsync back.  Forgot to
think about how to preserve existing kernel and supporting tree in place, so the
system's unbootable from hard drive.  

Probably not supposed to editorialize here, but the re-sync should be easy to
work through since I just had to do it this week on a workstation that I
attempted Fedora 9 preupgrade on.  Also a disaster.
Comment 6 Kyle McMartin 2008-07-13 13:35:11 EDT
Erk, crap, I just kind of assumed people had upgraded. I'll post a link to an F8
scratch build when it completes.

cheers, Kyle
Comment 7 W.C. Epperson 2008-07-13 17:39:29 EDT
Thanks, Kyle, that will be helpful.  After all, the bug _was_ opened against
2.6.25.9-40.fc8.i686.  And I would have everything at 9 by now, but my test case
for preupgrade was seriously hosed after the upgrade completed (yum, httpd, and
cupsd all throwing module errors, looked like the upgrade was clueless about
replacing necessary packages from F8).

Will try again when you post an F8 link.  Interesting that packages are still
being labeled fc8 and fc9, two and three versions after "core" was retired from
the nomenclature.  Oops, there I go editorializing again.
Comment 8 Kyle McMartin 2008-07-14 19:57:55 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=714370

(hopefully you don't need ppc64, but everything else should be fine :)
Comment 9 W.C. Epperson 2008-07-14 21:39:32 EDT
This kernel unfortunately and surprisingly does not fix bug 454954, which also
began occurring at the time CONFIG_ACPI_SYSFS_POWER was turned on.  It does fix
bug 373041.
Comment 10 Nicolas A. Barriga 2008-07-18 16:55:25 EDT
Isn't this a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=451896 ?
Comment 11 W.C. Epperson 2008-07-18 17:28:51 EDT
Except for that being against F9, it appears to be the same issue.
Comment 12 Matthias Scheutz 2008-07-22 14:09:18 EDT
I'm running Linux hri 2.6.25.10-47.fc8 on a Dell D830 and I'm still having this
problem (and it's been there for a while, i.e., several kernels).
Comment 13 Kyle McMartin 2008-07-22 16:09:58 EDT
I just kicked off an F8 & F9 build which should fix this issue. The commit was
3c1e3896344063273715b332b1c0534deb9b286c, and it was caused by a few patches we
had backported from 2.6.26 (but missed this one.)

cheers, Kyle
Comment 14 W.C. Epperson 2008-07-22 18:24:44 EDT
That's terrific, and a fix of any kind will be welcome?  How can we know when
this fix has made its way to the kernels in the fedora repos, so we can remove
kernel from the yum.conf exclude list? When the repo kernel reaches the version
number of your build?

Also, you're not building kernel-headers, which could cause issues for dkms
modules in particular, I think.  Not a problem for me on this laptop, but
something to consider, perhaps.  Thanks for your valuable work.
Comment 15 Kyle McMartin 2008-07-23 12:50:13 EDT
Can you please test
http://koji.fedoraproject.org/koji/buildinfo?buildID=57100
(it has kernel-headers built as well.)

(F9 version at http://koji.fedoraproject.org/koji/taskinfo?taskID=732403 when it
finishes building... unfortunately it failed due to the builder running out of
space.)


cheers, Kyle
Comment 16 Nicolas A. Barriga 2008-07-23 14:08:21 EDT
I just tested the kernel for F9, and it doesn't fix the issue.
Comment 17 Kyle McMartin 2008-07-23 14:24:19 EDT
Er, you probably didn't test the right kernel, given it didn't actually build on
anything useful... I've requeued it a third time, hopefully koji actually builds
it this time.
Comment 18 Nicolas A. Barriga 2008-07-23 18:59:57 EDT
Really? mmm, then I guess I don't understand the build system. What did I 
download from http://koji.fedoraproject.org/koji/taskinfo?taskID=732433 then?

http://koji.fedoraproject.org/koji/getfile?
taskID=732433&name=kernel-2.6.25.11-99.fc9.x86_64.rpm

It boots and reports to be 2.6.25.11-99.fc9.x86_64
Comment 19 W.C. Epperson 2008-07-23 19:23:38 EDT
Installed:
kernel-2.6.25.11-61.fc8.i686.rpm
kernel-devel-2.6.25.11-61.fc8.i686.rpm
kernel-doc-2.6.25.11-61.fc8.noarch.rpm
kernel-headers-2.6.25.11-61.fc8.i386.rpm
using yum localinstall to preserve previous kernel.

Still seeing same behavior from kacpid and company after resume:
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
                                            
   62 root      39  19     0    0    0 R 41.5  0.0   2:36.36 kacpi_notify      
                                             
   61 root      39  19     0    0    0 S 37.5  0.0   2:20.88 kacpid 

Will check hibernate and re-comment if the behavior after resume is any different.
Comment 20 W.C. Epperson 2008-07-23 20:36:55 EDT
Same kacpi* behavior after hibernate/resume.  BTW, the "top" display above is
after re-nicing.  Makes the system usable, but the CPU stays pegged, so battery
life is abysmal.
Comment 21 Dan Lechner 2008-07-24 10:49:03 EDT
Not sure if i should add to this bug or start a new one - new at this.. i have 
a dual core T5088 emachine desktop running vista.  just installed newest ubuntu 
(8.04) and fedora (fc9) on it - both linux distros have kacpid and kacpi_notify 
consuming 40-90 pct cpu.  hd powers up and down constantly, guessing it sounds 
like its spinning 30-60 pct based on sound, even when hardly anything is 
running on system.  vista runs quiet as a mouse.  i have same linux distros on 
another emachine (not dual core), and they run fine on them.  kacpid hardly 
uses anything on the other machine.  i tried turning off acpi through 
apps>system settings, but that didn't change anything.  if i set acpi=off in 
menu.lst and reboot, hd is quiet, kacpid does not use resource (looking at top 
output), but i can't connect to internet.  rebooted a couple of times to verify.
Comment 22 Dan Lechner 2008-07-24 15:44:05 EDT
sorry, my T5088 is not dual core.  Pent 4 processor 641.  i am also wondering 
if the smart drive (sata) could have anything to do with kacpid using most of 
cpu, running almost all of the time, and causing hd to power up and down 
frequently?
Comment 23 Dan Lechner 2008-07-24 15:45:47 EDT
sorry again.  i probably should have put my comments in a fc9 thread instead of 
this one.  from reading other posts, i think the problems exists in fc8 and 
fc9, but i am running fc9 on this pc.
Comment 24 Patrice Dumas 2008-07-29 08:45:48 EDT
It also happens on adell latitude D505 with latest rawhide kernel:
2.6.27-0.186.rc0.git15.fc10.i586
Comment 25 Fedora Update System 2008-08-04 09:43:08 EDT
kernel-2.6.25.14-68.fc8 has been submitted as an update for Fedora 8
Comment 26 W.C. Epperson 2008-08-04 10:51:50 EDT
2.6.25.11-61.fc8 did not fix the problem.  Is there some change in kernel-2.6.25.14-68.fc8 that is thought to have a bearing on the issue?
Comment 27 Fedora Update System 2008-08-07 20:00:15 EDT
kernel-2.6.25.14-69.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-7128
Comment 28 Patrice Dumas 2008-08-08 10:40:48 EDT
Still not fixed in rawhide 
 2.6.27-0.238.rc2.fc10.i586
Comment 29 Fedora Update System 2008-08-12 14:22:27 EDT
kernel-2.6.25.14-69.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 30 W.C. Epperson 2008-08-12 18:37:44 EDT
kernel-2.6.25.14-69.fc8 is not being picked up by "yum clean all;yum update", although I can see the rpm at:
http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386/

"yum list installed kernel" says:
kernel.i686                              2.6.25.11-54.fc8       installed       
kernel.i686                              2.6.25.9-40.fc8        installed       
kernel.i686                              2.6.25.11-60.fc8       installed

"yum list available kernel" says:
kernel.i586                              2.6.25.11-60.fc8       updates
Comment 31 W.C. Epperson 2008-08-12 19:02:38 EDT
Ah.  kernel-2.6.25.14-69.fc8 not mirrored yet.  Disabled mirrorlist and ran with just baseurl and picked it up.
Comment 32 W.C. Epperson 2008-08-12 19:23:04 EDT
Not fixed in kernel-2.6.25.14-69.fc8:
   62 root       0 -20     0    0    0 S 44.5  0.0   0:40.38 kacpi_notify       
   61 root       0 -20     0    0    0 R 40.8  0.0   0:36.10 kacpid 

After noting that the pair always get the same pids, I've discovered that if I
renice +20 61 62
in rc.local, the post-resume usage is cut approximately in half, making the system much more usable, and allowing cpufreq to do at least _some_ throttling, extending battery runtime.  Waiting to renice _after_ the problem occurs does not have nearly as much effect.  Very strange.
Comment 33 Dmitry Teytelman 2008-08-31 05:22:03 EDT
I've made some tests on Dell D610 and D520 laptops. Both with fully updated Fedora 8 installations. For kernels <= 2.6.25.4-10 there are no problems with kacpid/kacpi_notify. With kernel versions above that I see the following:

1. When the laptop boots with the media bay populated with CD-ROM drive (CD-RW, DVD-RW, DVD-R all have the same effect), suspend causes no problems.

2. If the CD-ROM drive is unregistered (using echo "scsi remove-single-device 1 0 0 0" > /proc/scsi/scsi) and unplugged, kacpid/kacpi_notify start running at full load. Inserting the drive back cures the problem (without reboot).

3. If the laptop is booted with the media bay empty (or with a battery), suspend cycle starts the kacpid/kacpi_notify problem. Inserting CD-ROM drive at this point fixes the problem, just like in the previous case.
Comment 34 Nicolas A. Barriga 2008-09-01 11:03:04 EDT
I don't have an optical drive, so this explains why I always have this problem.
Comment 35 Patrice Dumas 2008-09-01 11:16:14 EDT
I also have removed the CD/DVD reader, because it didn't worked
well.
Comment 36 Bug Zapper 2008-11-26 05:59:21 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 37 Patrice Dumas 2008-12-12 09:24:32 EST
Was still in f10 (at least without updates).
Comment 38 Mateusz M. 2009-10-18 03:41:08 EDT
Oct 17 08:51:47 localhost kernel: ------------[ cut here ]------------
Oct 17 08:51:47 localhost kernel: WARNING: at kernel/irq/manage.c:788 __free_irq+0xac/0x1bf() (Not tainted)
Oct 17 08:51:47 localhost kernel: Hardware name:         
Oct 17 08:51:47 localhost kernel: Trying to free already-free IRQ 16
Oct 17 08:51:47 localhost kernel: Modules linked in: fuse bridge stp llc xt_physdev ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv6 xt_multiport ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm_intel kvm snd_hda_codec_atihdmi snd_hda_codec_realtek uvcvideo videodev snd_hda_intel snd_hda_codec arc4 ecb snd_hwdep snd_pcm v4l1_compat sdhci_pci snd_timer snd ath9k mac80211 iTCO_wdt ath v4l2_compat_ioctl32 sdhci cfg80211 soundcore iTCO_vendor_support rfkill mmc_core joydev jmb38x_ms lirc_ene0100 memstick i2c_i801 snd_page_alloc tpm_infineon lirc_dev r8169 mii video output radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Oct 17 08:51:47 localhost kernel: Pid: 20, comm: kacpi_notify Not tainted 2.6.31.4-84.fc12.x86_64 #1
Oct 17 08:51:47 localhost kernel: Call Trace:
Oct 17 08:51:47 localhost kernel: [<ffffffff810642c0>] warn_slowpath_common+0x95/0xc3
Oct 17 08:51:47 localhost kernel: [<ffffffff810c9a49>] ? __free_irq+0x7e/0x1bf
Oct 17 08:51:47 localhost kernel: [<ffffffff8106437b>] warn_slowpath_fmt+0x50/0x66
Oct 17 08:51:47 localhost kernel: [<ffffffff810c9a49>] ? __free_irq+0x7e/0x1bf
Oct 17 08:51:47 localhost kernel: [<ffffffff810c9a77>] __free_irq+0xac/0x1bf
Oct 17 08:51:47 localhost kernel: [<ffffffff810c9bab>] free_irq+0x21/0x3f
Oct 17 08:51:47 localhost kernel: [<ffffffffa01785bc>] sdhci_remove_host+0xdb/0x14c [sdhci]
Oct 17 08:51:47 localhost kernel: [<ffffffffa021d40f>] sdhci_pci_remove_slot+0x43/0x92 [sdhci_pci]
Oct 17 08:51:47 localhost kernel: [<ffffffffa021d7bb>] sdhci_pci_remove+0x45/0x85 [sdhci_pci]
Oct 17 08:51:47 localhost kernel: [<ffffffff812998bc>] pci_device_remove+0x40/0x7a
Oct 17 08:51:47 localhost kernel: [<ffffffff81353973>] __device_release_driver+0x7f/0xde
Oct 17 08:51:47 localhost kernel: [<ffffffff81353aee>] device_release_driver+0x36/0x59
Oct 17 08:51:47 localhost kernel: [<ffffffff8135294b>] bus_remove_device+0xd7/0x122
Oct 17 08:51:47 localhost kernel: [<ffffffff8135024b>] device_del+0x146/0x1ab
Oct 17 08:51:47 localhost kernel: [<ffffffff813502f3>] device_unregister+0x43/0x83
Oct 17 08:51:47 localhost kernel: [<ffffffff812936e8>] pci_stop_bus_device+0x70/0xa9
Oct 17 08:51:47 localhost kernel: [<ffffffff812ab06e>] acpiphp_disable_slot+0xa6/0x1cf
Oct 17 08:51:47 localhost kernel: [<ffffffff812ab32e>] acpiphp_check_bridge+0x4e/0xf7
Oct 17 08:51:47 localhost kernel: [<ffffffff812d01ea>] ? acpi_os_execute_deferred+0x0/0x63
Oct 17 08:51:47 localhost kernel: [<ffffffff812ab64c>] handle_hotplug_event_bridge+0x275/0x3c7
Oct 17 08:51:47 localhost kernel: [<ffffffff812eec6d>] ? acpi_get_data+0x79/0xa3
Oct 17 08:51:47 localhost kernel: [<ffffffff812d2a5f>] ? acpi_bus_get_device+0x39/0x63
Oct 17 08:51:47 localhost kernel: [<ffffffff812e3b15>] acpi_ev_notify_dispatch+0x73/0x96
Oct 17 08:51:47 localhost kernel: [<ffffffff812d022a>] acpi_os_execute_deferred+0x40/0x63
Oct 17 08:51:47 localhost kernel: [<ffffffff812d01ea>] ? acpi_os_execute_deferred+0x0/0x63
Oct 17 08:51:47 localhost kernel: [<ffffffff8107b490>] worker_thread+0x222/0x33e
Oct 17 08:51:47 localhost kernel: [<ffffffff8107b43b>] ? worker_thread+0x1cd/0x33e
Oct 17 08:51:47 localhost kernel: [<ffffffff81505b5f>] ? thread_return+0x4e/0xd3
Oct 17 08:51:47 localhost kernel: [<ffffffff810814eb>] ? autoremove_wake_function+0x0/0x5f
Oct 17 08:51:47 localhost kernel: [<ffffffff8107b26e>] ? worker_thread+0x0/0x33e
Oct 17 08:51:47 localhost kernel: [<ffffffff81081098>] kthread+0xac/0xb4
Oct 17 08:51:47 localhost kernel: [<ffffffff810131aa>] child_rip+0xa/0x20
Oct 17 08:51:47 localhost kernel: [<ffffffff81012b10>] ? restore_args+0x0/0x30
Oct 17 08:51:47 localhost kernel: [<ffffffff81080fec>] ? kthread+0x0/0xb4
Oct 17 08:51:47 localhost kernel: [<ffffffff810131a0>] ? child_rip+0x0/0x20
Oct 17 08:51:47 localhost kernel: ---[ end trace 5fd7cb60005126f9 ]---



Oct 17 08:59:20 localhost kernel: PM: resume devices took 4.498 seconds
Oct 17 08:59:20 localhost kernel: Restarting tasks ... done.
Oct 17 08:59:21 localhost kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
Oct 17 08:59:21 localhost kernel: Pid: 21691, comm: xkbcomp Tainted: G        W  2.6.31.4-84.fc12.x86_64 #1
Oct 17 08:59:21 localhost kernel: Call Trace:
Oct 17 08:59:21 localhost kernel: <IRQ>  [<ffffffff810ca10f>] __report_bad_irq+0x4a/0xb0
Oct 17 08:59:21 localhost kernel: [<ffffffff810ca29c>] note_interrupt+0x127/0x1a3
Oct 17 08:59:21 localhost kernel: [<ffffffff810cab53>] handle_fasteoi_irq+0xb9/0xf9
Oct 17 08:59:21 localhost kernel: [<ffffffff81014fcc>] handle_irq+0x9a/0xba
Oct 17 08:59:21 localhost kernel: [<ffffffff81507d35>] ? trace_hardirqs_off_thunk+0x3a/0x3c
Oct 17 08:59:21 localhost kernel: [<ffffffff8150d98f>] do_IRQ+0x6f/0xe5
Oct 17 08:59:21 localhost kernel: [<ffffffff81012a53>] ret_from_intr+0x0/0x16
Oct 17 08:59:21 localhost kernel: <EOI> 
Oct 17 08:59:21 localhost kernel: handlers:
Oct 17 08:59:21 localhost kernel: [<ffffffff813b387a>] (usb_hcd_irq+0x0/0xcc)
Oct 17 08:59:21 localhost kernel: [<ffffffffa01d9f23>] (ath_isr+0x0/0x174 [ath9k])
Oct 17 08:59:21 localhost kernel: Disabling IRQ #18
Oct 17 08:59:21 localhost kernel:
Oct 17 08:59:21 localhost kernel: =================================
Oct 17 08:59:21 localhost kernel: [ INFO: inconsistent lock state ]
Oct 17 08:59:21 localhost kernel: 2.6.31.4-84.fc12.x86_64 #1
Oct 17 08:59:21 localhost kernel: ---------------------------------
Oct 17 08:59:21 localhost kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 17 08:59:21 localhost kernel: unix_chkpwd/21696 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 17 08:59:21 localhost kernel: (&irq_desc_lock_class){?.-...}, at: [<ffffffff810c9ec8>] try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: {IN-HARDIRQ-W} state was registered at:
Oct 17 08:59:21 localhost kernel:  [<ffffffff81096f4f>] __lock_acquire+0x254/0xc0e
Oct 17 08:59:21 localhost kernel:  [<ffffffff810979f7>] lock_acquire+0xee/0x12e
Oct 17 08:59:21 localhost kernel:  [<ffffffff815085e7>] _spin_lock+0x45/0x8e
Oct 17 08:59:21 localhost kernel:  [<ffffffff810cabc8>] handle_level_irq+0x35/0xf9
Oct 17 08:59:21 localhost kernel:  [<ffffffff81014fcc>] handle_irq+0x9a/0xba
Oct 17 08:59:21 localhost kernel:  [<ffffffff8150d98f>] do_IRQ+0x6f/0xe5
Oct 17 08:59:21 localhost kernel:  [<ffffffff81012a53>] ret_from_intr+0x0/0x16
Oct 17 08:59:21 localhost kernel:  [<ffffffffffffffff>] 0xffffffffffffffff
Oct 17 08:59:21 localhost kernel: irq event stamp: 11854
Oct 17 08:59:21 localhost kernel: hardirqs last  enabled at (11854): [<ffffffff815082e3>] _spin_unlock_irq+0x3f/0x61
Oct 17 08:59:21 localhost kernel: hardirqs last disabled at (11853): [<ffffffff815086f1>] _spin_lock_irq+0x2e/0x9a
Oct 17 08:59:21 localhost kernel: softirqs last  enabled at (11842): [<ffffffff8106c0bc>] __do_softirq+0x1c4/0x1f0
Oct 17 08:59:21 localhost kernel: softirqs last disabled at (11851): [<ffffffff810132ac>] call_softirq+0x1c/0x30
Oct 17 08:59:21 localhost kernel:
Oct 17 08:59:21 localhost kernel: other info that might help us debug this:
Oct 17 08:59:21 localhost kernel: 1 lock held by unix_chkpwd/21696:
Oct 17 08:59:21 localhost kernel: #0:  (kernel/irq/spurious.c:21){+.-...}, at: [<ffffffff81071a4a>] run_timer_softirq+0x198/0x2a3
Oct 17 08:59:21 localhost kernel:
Oct 17 08:59:21 localhost kernel: stack backtrace:
Oct 17 08:59:21 localhost kernel: Pid: 21696, comm: unix_chkpwd Tainted: G        W  2.6.31.4-84.fc12.x86_64 #1
Oct 17 08:59:21 localhost kernel: Call Trace:
Oct 17 08:59:21 localhost kernel: <IRQ>  [<ffffffff81095af3>] valid_state+0x187/0x1ae
Oct 17 08:59:21 localhost kernel: [<ffffffff810965e6>] ? check_usage_backwards+0x0/0x76
Oct 17 08:59:21 localhost kernel: [<ffffffff81095c43>] mark_lock+0x129/0x253
Oct 17 08:59:21 localhost kernel: [<ffffffff81096fc3>] __lock_acquire+0x2c8/0xc0e
Oct 17 08:59:21 localhost kernel: [<ffffffff810c9ec8>] ? try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: [<ffffffff810979f7>] lock_acquire+0xee/0x12e
Oct 17 08:59:21 localhost kernel: [<ffffffff810c9ec8>] ? try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: [<ffffffff81287c38>] ? debug_object_deactivate+0x47/0xf2
Oct 17 08:59:21 localhost kernel: [<ffffffff810c9ec8>] ? try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: [<ffffffff815085e7>] _spin_lock+0x45/0x8e
Oct 17 08:59:21 localhost kernel: [<ffffffff810c9ec8>] ? try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: [<ffffffff810c9ec8>] try_one_irq+0x37/0x13d
Oct 17 08:59:21 localhost kernel: [<ffffffff810ca040>] ? poll_spurious_irqs+0x0/0x4e
Oct 17 08:59:21 localhost kernel: [<ffffffff810ca014>] poll_all_shared_irqs+0x46/0x72
Oct 17 08:59:21 localhost kernel: [<ffffffff810ca061>] poll_spurious_irqs+0x21/0x4e
Oct 17 08:59:21 localhost kernel: [<ffffffff81071aae>] run_timer_softirq+0x1fc/0x2a3
Oct 17 08:59:21 localhost kernel: [<ffffffff81071a4a>] ? run_timer_softirq+0x198/0x2a3
Oct 17 08:59:21 localhost kernel: [<ffffffff8108b68e>] ? clocksource_read+0x22/0x38
Oct 17 08:59:21 localhost kernel: [<ffffffff8106bfee>] __do_softirq+0xf6/0x1f0
Oct 17 08:59:21 localhost kernel: [<ffffffff810132ac>] call_softirq+0x1c/0x30
Oct 17 08:59:21 localhost kernel: [<ffffffff81014d13>] do_softirq+0x5f/0xd7
Oct 17 08:59:21 localhost kernel: [<ffffffff8106b905>] irq_exit+0x66/0xbc
Oct 17 08:59:21 localhost kernel: [<ffffffff8150da9e>] smp_apic_timer_interrupt+0x99/0xbf
Oct 17 08:59:21 localhost kernel: [<ffffffff81012c73>] apic_timer_interrupt+0x13/0x20
Comment 39 W.C. Epperson 2009-10-18 10:26:17 EDT
And your point is?
Comment 40 Bug Zapper 2009-11-18 04:36:33 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 41 Bug Zapper 2009-12-18 01:14:36 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.