Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I updated Gentoo. My current kernel is 2.6.19-gentoo-r5 Pentium(R) M processor 1.60GHz. System logs (/var/log/acpi ) floods with messages like. Seems to be coming from CONFIG_ACPI_PROCESSOR. Reproducible: Always Steps to Reproduce: When I compile the kernel to use CONFIG_ACPI_PROCESSOR: | Prompt: Processor │ │ Defined at drivers/acpi/Kconfig:141 │ │ Depends on: !X86_VOYAGER && !X86_VISWS && !IA64_HP_SIM && (IA64 || X8 │ │ Location: │ │ -> Power management options (ACPI, APM) │ │ -> ACPI (Advanced Configuration and Power Interface) Support │ │ -> ACPI Support (ACPI [=y] and CPU Frequency scaling (module: speedstep_centrino) system logs (/var/log/acpi ) floods with event messages. Actual Results: [Fri Mar 23 00:22:36 2007] received event "processor CPU1 00000080 00000004" [Fri Mar 23 00:22:36 2007] notifying client 5512[103:409] [Fri Mar 23 00:22:36 2007] notifying client 5785[0:0] [Fri Mar 23 00:22:36 2007] executing action "/etc/acpi/default.sh processor CPU1 00000080 00000004" [Fri Mar 23 00:22:36 2007] BEGIN HANDLER MESSAGES [Fri Mar 23 00:22:36 2007] END HANDLER MESSAGES [Fri Mar 23 00:22:36 2007] action exited with status 0 [Fri Mar 23 00:22:36 2007] completed event "processor CPU1 00000080 00000004" [Fri Mar 23 00:22:52 2007] received event "processor CPU1 00000080 00000004" [Fri Mar 23 00:22:52 2007] notifying client 5512[103:409] [Fri Mar 23 00:22:52 2007] notifying client 5785[0:0] [Fri Mar 23 00:22:52 2007] executing action "/etc/acpi/default.sh processor CPU1 00000080 00000004" [Fri Mar 23 00:22:52 2007] BEGIN HANDLER MESSAGES [Fri Mar 23 00:22:52 2007] END HANDLER MESSAGES [Fri Mar 23 00:22:52 2007] action exited with status 0 [Fri Mar 23 00:22:52 2007] completed event "processor CPU1 00000080 00000004" ACPI Processor seems to be needed for speedstep_centrino and CPU frequency scaling to work. Removing ACPI Processor support stops the messages, and brakes speedstep_centrino.
This is an ACPI event signalling that the processor performance state has changed to P-state 4, but your logs just indicate the same message is coming in again and again.
Which kernel did you upgrade from? Can you test 2.6.20, and if the bug still exists, the latest development kernel (currently 2.6.21-rc5)? Thanks in advance.
I upgraded from kernel-2.6.14-gentoo-r5, however that kernel didn't have ACPI for CPU power management configured. I just tried 2.6.20-gentoo-r4 and the problem still exists. Can I somehow emerge 2.6.21, or do I have to download from kernel.org.
-rc releases aren't in portage at the moment. You can use ketchup: # emerge -n ketchup # mkdir /usr/src/linux-2.6.21-rc5 # cd /usr/src/linux-2.6.21-rc5 # ketchup 2.6.21-rc5
I tried with 2.6.21-rc5. The ACPI events continue to flood the logs. Some changes I noticed are: o) I have to use acpi_cpufreq module instead of speedstep_centrino o) the ACPI events seem to be more far apart. For the sort time I used the kernel, they were exactly 30 sec apart from each other. My CPU info (as reported by 2.6.20-gentoo-r4 and no processor ACPI events) is: #cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 6 cpu MHz : 1600.161 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips : 3202.06 clflush size : 64
Please file this upstream as an ACPI bug on 2.6.21-rc5 at http://bugzilla.kernel.org. Post the new bug here when done and I'll track it.
Filed it in http://bugzilla.kernel.org. Bug id is 8288. http://bugzilla.kernel.org/show_bug.cgi?id=8288 Thank you.
I recognize a dependency on the following setting in kde: Control Center -> Power Control -> Laptop Battery -> Battery ... Check status every [X] sec. If i change X, the time between the messages changed to X, too. So I think it is a problem with KLaptop. Can some one confirm this?
> If i change X, the time between the messages changed to X, too. > So I think it is a problem with KLaptop. > Can some one confirm this? Yes, the messages in my case are also related with klaptop. Also they seem to be related to hald-addon-acpi, and maybe the ac module. See: http://bugzilla.kernel.org/show_bug.cgi?id=8288#c4 Oliver, can you confirm that this is not an Intel specific issue? Is it more appropriate to report this also upstreams (bugzilla.kernel.org)?
I'm using AMD64 with vanilla Kernel: $ uname -a Linux genlap2 2.6.23.1 #1 Sat Oct 13 01:53:32 CEST 2007 i686 Mobile AMD Athlon(tm) 64 Processor 2800+ AuthenticAMD GNU/Linux So, it is not Intel specific. Should we reopen the bug report?
Reopening... Same problem reported in different environments. See also: (German) http://forums.gentoo.org/viewtopic-p-4377695.html?sid=7a2e792515bb56dafe3f7c1336fd8cfa
Oliver, does the patch in the upstream bug report also fix the problem for you?
upstream commit e790cc8bbb990df900eabdda18a5a480d22a60c8 includes this patch (looks like it was accidentally brought into that commit, but hey!)
this was fixed in gentoo-sources-2.6.23-r4
This problem persists on gentoo-sources-2.6.31. I've set up acpid to "ignore" the event in the /etc/acpi/default.sh, but it still isn't the brightest idea to execute a process on each CPU state change (especially considering that these changes happen in an effort to reduce the CPU power, after all...
(In reply to comment #15) > This problem persists on gentoo-sources-2.6.31. I've set up acpid to "ignore" > the event in the /etc/acpi/default.sh, but it still isn't the brightest idea to > execute a process on each CPU state change (especially considering that these > changes happen in an effort to reduce the CPU power, after all... > I see. So, while gentoo-sources-2.6.30 wasn't reporting such errors, gentoo-sources-2.6.31 started reporting them again? Could we have a copy of your /var/log/acpi and your dmesg for both kernels (2.6.30 and 2.6.31)? Thanks!
(In reply to comment #16) > So, while gentoo-sources-2.6.30 wasn't reporting such errors, > gentoo-sources-2.6.31 started reporting them again? Unfortunately I went from 2.6.26-gentoo-r1 to 2.6.31-gentoo. > Could we have a copy of your /var/log/acpi and your dmesg for both kernels > (2.6.30 and 2.6.31)? I could provide dmesg from the older kernel, but don't see much point in doing that. I'll be attaching dmesg from the new one shortly. As of the acpid log, the easiest way to get them is `acpi_listen`, which reports a stream of the following: velbloud ~ # acpi_listen processor CPU0 00000080 00000002 processor CPU1 00000080 00000002 processor CPU0 00000080 00000000 processor CPU1 00000080 00000000 processor CPU0 00000080 00000002 processor CPU1 00000080 00000002 processor CPU0 00000080 00000000 processor CPU1 00000080 00000000 processor CPU0 00000080 00000002 processor CPU1 00000080 00000002 processor CPU0 00000080 00000000 processor CPU1 00000080 00000000 whenever there is some significant CPU activity which triggers frequency transitions (simply running `while true; do true; done` in another shell is enough). This happens on a Thinkpad T60 (2007-FRG) with the ondemand CPU governor and acpi-cpufreq cpufreq driver.
Created an attachment (id=204664) [details] dmesg-2.6.26-gentoo-r1
Created an attachment (id=204666) [details] dmesg-2.6.31-gentoo This one looks a bit strange (no "2.6.31 booting" message), but it's all that is recorded in my kern.log.
(In reply to comment #17) > (In reply to comment #16) > > So, while gentoo-sources-2.6.30 wasn't reporting such errors, > > gentoo-sources-2.6.31 started reporting them again? > > Unfortunately I went from 2.6.26-gentoo-r1 to 2.6.31-gentoo. > > > Could we have a copy of your /var/log/acpi and your dmesg for both kernels > > (2.6.30 and 2.6.31)? > > I could provide dmesg from the older kernel, but don't see much point in doing > that. I'll be attaching dmesg from the new one shortly. > > As of the acpid log, the easiest way to get them is `acpi_listen`, which > reports a stream of the following: > > velbloud ~ # acpi_listen > processor CPU0 00000080 00000002 > processor CPU1 00000080 00000002 > processor CPU0 00000080 00000000 > processor CPU1 00000080 00000000 > processor CPU0 00000080 00000002 > processor CPU1 00000080 00000002 > processor CPU0 00000080 00000000 > processor CPU1 00000080 00000000 > processor CPU0 00000080 00000002 > processor CPU1 00000080 00000002 > processor CPU0 00000080 00000000 > processor CPU1 00000080 00000000 > > whenever there is some significant CPU activity which triggers frequency > transitions (simply running `while true; do true; done` in another shell is > enough). This happens on a Thinkpad T60 (2007-FRG) with the ondemand CPU > governor and acpi-cpufreq cpufreq driver. > So basically you are getting these errors when there is high CPU activity AND when klaptop probes for battery status?
