Distribution: gentoo Hardware Environment: ibm thinkpad a22e; intel 82440mx chipset; integrated audio controller in the 82440mx (snd-intel8x0/i810_audio drivers) Software Environment: n/a Problem Description: 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 result? ===== 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- i386/param.h) 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 states: *C1: promotion[C2] demotion[--] latency[000] usage[00052613] C2: promotion[C3] demotion[C1] latency[001] usage[02994912] C3: promotion[--] demotion[C2] latency[065] usage[01052098]
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] random 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 transition ratio.
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.