Hardware Environment: ibm thinkpad a22e; intel 82440mx chipset; integrated audio
controller in the 82440mx (snd-intel8x0/i810_audio drivers)
Software Environment: n/a
sound card emits a constant high-pitched tone when acpi support is loaded and
cpu is idle; if cpu is busy, or if acpi support is turned off with acpi=off
kernel parameter, the problem does not occur. this problem occurs with both alsa
(snd-intel8x0) and oss (i810_audio) drivers for the audio card. the noise did
not occur in windows XP (as the laptop had it installed when i bought it; it no
longer has windows, so i cannot do any further windows testing).
Steps to reproduce:
boot kernel 2.6.8 with acpi support enabled on an ibm thinkpad a22e with intel
82440mx integrated audio card (if running alsa, unmute master and pcm channels
and set them above 75%; other channels' settings do not seem to matter).
Suppose it's a C-state problem. If you apply the below test patch, what's
===== processor.c 1.61 vs edited =====
--- 1.61/drivers/acpi/processor.c 2004-08-31 23:27:29 +08:00
+++ edited/drivers/acpi/processor.c 2004-09-16 09:18:59 +08:00
@@ -719,7 +719,7 @@
pr->flags.bm_check = 1;
+ pr->power.states[ACPI_STATE_C3].valid = 0;
* Set Default Policy
In addition, how about change the 'ACPI_STATE_C3' above into 'ACPI_STATE_C2'?
Or what's the result if you set both (C2 and C3)to 0?
yes, disabling the C3 state as you described got rid of the buzzing tone.
I'd bet it will also change if you drop HZ to 100 from 1000 (in include/asm-
If so, there is a "singing capacitor" on the motherboard that is vibrating
every time it is charged/discharged (such as entering C3). 1000 HZ is audible.
Windows uses a 100HZ system timer by default, so that's why you didn't hear it
on that OS.
There's no short-term solution. The real solution (IMHO) is to get Linux back
to using a 100 HZ timer, perhaps using higher granularity only when required.
is it safe to switch to 100hz? i could not find much information regarding the
100hz -> 1000hz change in the 2.6 kernels, but i did find patches fixing code
that relied on HZ=1000 at some point in the history of the 2.6 tree... it seems
it would be much better to have a working C3 power state (this is a laptop after
all) than having a 1000hz timer (which as far as i understand only improves
responsiveness a bit).
Sure, it's safe. You can change HZ to 100 in 'asm-i386/param.h'
unfortunately, the 100hz buzz from the 100hz kernel timer is still very audible.
i'm certain there wasn't even such a low buzz on winxp, so probably the kernel
timer is not the only difference that made the sound card noiseless on
windows... so i'm back to 1000hz timer with no C3 power state :(
any other pointers? should i provide a full bug report (dmesg, acpidmp,
dmidecode and lspci), will it be of any help?
I'd like to see output of /proc/acpi/processor/CPU0/power.
As what Andy said, it could be a issue like "sympathetic vibration".
Can we just add some randomness in promotion/demotion algorithm of C3.
here is /proc/acpi/processor/CPU/power, after roughly 15 minutes of casual usage
of the machine:
active state: C1
default state: C1
bus master activity: ffffffff
*C1: promotion[C2] demotion[--] latency usage
C2: promotion[C3] demotion[C1] latency usage
C3: promotion[--] demotion[C2] latency usage
Created attachment 3704 [details]
a debug patch
This is a debug patch to add randomness factor into promotion/demotion
algorithm. Please give it a try.
tried the patch - made the sound much more noisy, but not less noticeable.
Created attachment 3724 [details]
Please try this patch, which will limit the chance of enterning C3 to 25% of
the normal, And see if it is better. Not sure if each transition of c3 could
generate noise. Maybe we can dig out the realtionship through turning C3/C2
tried this patch too, and there does not seem to be much difference from the
last patch - the sound is there, still noisy from the randomness.
a bunch of Dell's suffer from noise in C3 also.
closing this bug as a duplicate of the workaround -- to disable C3.
*** This bug has been marked as a duplicate of 3549 ***
*** Bug 2478 has been marked as a duplicate of this bug. ***
There seems to be more with this issue: disabling the C3 state might not be necessary.
In my configuration, I also get the noise, and indeed disabling the C3 state stops the noise (on 2.6.18, modprobe -r processor && modprobe processor max_cstate=2 , and no noise).
But, when C3 is enabled, there is a way to make the noise away without causing much extra processor activity: I start playing music, and then pause. The noise is away (as long as the player is paused, not closed).
With noise I have roughly the following CPU states usage (shown by powertop):
C0:10% C1:0% C2:34% C3:56%;
without noise when the player is paused it's:
C0:11% C1:0% C2:35% C3:54%.
This indicates that the usage of the C3 state is roughly the same, even when the noise is away, doesn't it?
Perhaps, some change in the audio device state makes the difference.
(Also, I checked that there is no noise in Windows.)
So, perhaps this information from me will be useful for someone.
(And I wonder does disabling the C3 state increases power consumption?)
My computer is Dell Latitude D610,
processor: Intel(R) Pentium(R) M processor 2.00GHz,
Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03),
Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03);
2.6.18 kernel, snd_intel8x0 from ALSA 1.0.14.
More on paused playback making the noise away:
actually, *no* running activity (at least, in userspace) is required to achieve silence, it's sufficient to do `runbg /usr/bin/aplay --nonblock /dev/zero && sleep 0.1 && killall -STOP /usr/bin/aplay' to achieve silence.