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
Also see 373041, which relates to the same kernel update and appears acpi related.
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
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.
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.
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.
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
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.
http://koji.fedoraproject.org/koji/taskinfo?taskID=714370 (hopefully you don't need ppc64, but everything else should be fine :)
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.
Isn't this a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=451896 ?
Except for that being against F9, it appears to be the same issue.
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).
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
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.
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
I just tested the kernel for F9, and it doesn't fix the issue.
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.
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
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.
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.
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.
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?
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.
It also happens on adell latitude D505 with latest rawhide kernel: 2.6.27-0.186.rc0.git15.fc10.i586
kernel-2.6.25.14-68.fc8 has been submitted as an update for Fedora 8
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?
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
Still not fixed in rawhide 2.6.27-0.238.rc2.fc10.i586
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.
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
Ah. kernel-2.6.25.14-69.fc8 not mirrored yet. Disabled mirrorlist and ran with just baseurl and picked it up.
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.
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.
I don't have an optical drive, so this explains why I always have this problem.
I also have removed the CD/DVD reader, because it didn't worked well.
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
Was still in f10 (at least without updates).
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
And your point is?
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
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.