Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 171860 - acpi logs flood by "processor CPU1" events
Summary: acpi logs flood by "processor CPU1" events
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL: http://bugzilla.kernel.org/show_bug.c...
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2007-03-22 22:34 UTC by Michalis Giannakidis
Modified: 2010-01-12 14:39 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dmesg-2.6.26-gentoo-r1 (dmesg-2.6.26-r1,41.64 KB, text/plain)
2009-09-20 09:26 UTC, Jan Kundrát (RETIRED)
Details
dmesg-2.6.31-gentoo (dmesg-2.6.31,46.88 KB, text/plain)
2009-09-20 09:28 UTC, Jan Kundrát (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michalis Giannakidis 2007-03-22 22:34:16 UTC
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.
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2007-03-23 23:49:32 UTC
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.
Comment 2 Daniel Drake (RETIRED) gentoo-dev 2007-03-28 00:46:27 UTC
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.
Comment 3 Michalis Giannakidis 2007-03-28 13:57:35 UTC
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.
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2007-03-28 19:47:31 UTC
-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
Comment 5 Michalis Giannakidis 2007-03-28 20:29:40 UTC
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


Comment 6 Daniel Drake (RETIRED) gentoo-dev 2007-03-30 23:38:27 UTC
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.
Comment 7 Michalis Giannakidis 2007-03-31 10:03:42 UTC
Filed it in http://bugzilla.kernel.org. Bug id is 8288.
http://bugzilla.kernel.org/show_bug.cgi?id=8288

Thank you.
Comment 8 Oliver Knodel 2007-10-27 21:35:28 UTC
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?
Comment 9 Michalis Giannakidis 2007-10-28 11:57:25 UTC
> 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)?
Comment 10 Oliver Knodel 2007-10-28 12:31:47 UTC
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?
Comment 11 Michalis Giannakidis 2007-10-31 19:18:55 UTC
Reopening...

Same problem reported in different environments.
See also: (German)
http://forums.gentoo.org/viewtopic-p-4377695.html?sid=7a2e792515bb56dafe3f7c1336fd8cfa

Comment 12 Daniel Drake (RETIRED) gentoo-dev 2007-11-27 18:46:37 UTC
Oliver, does the patch in the upstream bug report also fix the problem for you?
Comment 13 Daniel Drake (RETIRED) gentoo-dev 2007-11-27 18:49:31 UTC
upstream commit e790cc8bbb990df900eabdda18a5a480d22a60c8 includes this patch (looks like it was accidentally brought into that commit, but hey!)
Comment 14 Mike Pagano gentoo-dev 2007-12-15 12:55:41 UTC
this was fixed in gentoo-sources-2.6.23-r4
Comment 15 Jan Kundrát (RETIRED) gentoo-dev 2009-09-19 15:39:13 UTC
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...
Comment 16 George Kadianakis (RETIRED) gentoo-dev 2009-09-19 19:01:10 UTC
(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!
Comment 17 Jan Kundrát (RETIRED) gentoo-dev 2009-09-20 09:20:41 UTC
(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.
Comment 18 Jan Kundrát (RETIRED) gentoo-dev 2009-09-20 09:26:50 UTC
Created attachment 204664 [details]
dmesg-2.6.26-gentoo-r1
Comment 19 Jan Kundrát (RETIRED) gentoo-dev 2009-09-20 09:28:05 UTC
Created attachment 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.
Comment 20 George Kadianakis (RETIRED) gentoo-dev 2009-09-24 14:56:39 UTC
(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?