Idle loop causes speaker whine/buzz (!)

Idle loop causes speaker whine/buzz (!)

[Mike Perry]

Throw this one in the running for strangest bug ever:

For some reason, on 2.6.17-2.6.19(+others?) the acpi_processor_idle
loop enabled by CONFIG_ACPI_PROCESSOR is causing my laptop's speakers
to buzz.. If the option is disabled or built as a module (or if I run
both my CPUs' usage up to 100%), the speakers are silent.

I drilled a little further down, and it seems to have something to do
with the busmastering code. If I hack drivers/acpi/processor_core.c to
always set bm_control = 0, the whine goes away. Of course, disabling
bustmastering disables all C2 to C3 transitions, so maybe it is an
unrelated matter still..

Another datapoint: If I boot into single user mode, I can get an
(almost) silent mode of operation by removing uhci_ocd, or if I turn
off bluetooth via the switch on my laptop. However, other drivers are
involved in the buzz as well because if I do a full boot, killing
USB+bluetooth does not help.

proc is telling me the latency value for C3 is 57. To see if it was
perhaps rapid state transitions, I tried doubling the threshold.count
values for every state. Didn't seem to change the pitch or volume of
the whine...


So, any ideas? Is this a bug in linux-acpi, or my laptop's ACPI
support? Any way to tell? Windows doesn't whine, but Linux in VMware
in Windows does (again, only if the CPU is idle).


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Re: Idle loop causes speaker whine/buzz (!)

[Pavel Troller]

> Throw this one in the running for strangest bug ever:
> 
> For some reason, on 2.6.17-2.6.19(+others?) the acpi_processor_idle
> loop enabled by CONFIG_ACPI_PROCESSOR is causing my laptop's speakers
> to buzz.. If the option is disabled or built as a module (or if I run
> both my CPUs' usage up to 100%), the speakers are silent.
> 
Hi!
  Your problem is related to hardware - poor filtering of power buses, causing
current peaks to penetrate to the sound circuitry (or possibly causing some
other hardware like a ferrite transformer) to emit sound.
  By entering deeper sleep states (especially C3), power consumption of the
CPU substantially reduces. By returning to C0, it increases again. These
events happen periodically, thus causing a continuous wave to be produced.
  When the system is not idle (working), the acpi CPU module is removed (so no
sleeping) or USB is busy (so no C3, because of high BM activity), there is no
reason for the sound.
                   With regards, Pavel Troller

Re: Idle loop causes speaker whine/buzz (!)

[Mike Perry]

Thus spake Pavel Troller (patrol@sinus.cz):

> > For some reason, on 2.6.17-2.6.19(+others?) the acpi_processor_idle
> > loop enabled by CONFIG_ACPI_PROCESSOR is causing my laptop's speakers
> > to buzz.. If the option is disabled or built as a module (or if I run
> > both my CPUs' usage up to 100%), the speakers are silent.
>
>   Your problem is related to hardware - poor filtering of power buses, causing
> current peaks to penetrate to the sound circuitry (or possibly causing some
> other hardware like a ferrite transformer) to emit sound.
>   By entering deeper sleep states (especially C3), power consumption of the
> CPU substantially reduces. By returning to C0, it increases again. These
> events happen periodically, thus causing a continuous wave to be produced.
>   When the system is not idle (working), the acpi CPU module is removed (so no
> sleeping) or USB is busy (so no C3, because of high BM activity), there is no
> reason for the sound.

Is there currently any way to disable busmastering or C3 transitions
(without recompilation)? Or better: is it possible to make the system
less eager to transition into C3 or otherwise reduce the frequency of
these transitions? If I could just get the frequency of transitions to
get out of the audible range, my life would be a lot better.

What governs the transition rate when the machine is mostly idle? Is
it the product of threshold.count and the latency, or am I misreading
this?

I'm sure I'm not the only person in the world who is going to
experience this problem, even if others haven't figured out what it is
yet. I'm willing to provide a patch for a proc or boot parameter-tuned
workaround if you can point me in the right direction. 

Please understand it really is quite annoying, and I doubt the
manufacturer is going to have any mercy because their Windows install
doesn't have the problem..


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Re: Idle loop causes speaker whine/buzz (!)

[Henrique de Moraes Holschuh]

On Tue, 23 Jan 2007, Mike Perry wrote:
> Is there currently any way to disable busmastering or C3 transitions
> (without recompilation)? Or better: is it possible to make the system
> less eager to transition into C3 or otherwise reduce the frequency of
> these transitions? If I could just get the frequency of transitions to
> get out of the audible range, my life would be a lot better.

Read http://thinkwiki.org/wiki/Problem_with_high_pitch_noises, it may have
the answers.

> Please understand it really is quite annoying, and I doubt the
> manufacturer is going to have any mercy because their Windows install
> doesn't have the problem..

If Windows is doing as aggressive power management as Linux, or even more
aggressive power management, then we ought to find out what they're doing
that is different and doesn't cause the noise.  If it is just less
aggressive power management, well, let's hope this changes soon.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Idle loop causes speaker whine/buzz (!)

[Len Brown]

On Tuesday 23 January 2007 16:00, Henrique de Moraes Holschuh wrote:
> On Tue, 23 Jan 2007, Mike Perry wrote:
> > Is there currently any way to disable busmastering or C3 transitions
> > (without recompilation)? Or better: is it possible to make the system
> > less eager to transition into C3 or otherwise reduce the frequency of
> > these transitions? If I could just get the frequency of transitions to
> > get out of the audible range, my life would be a lot better.
> 
> Read http://thinkwiki.org/wiki/Problem_with_high_pitch_noises, it may have
> the answers.

Pretty good write-up.  It is correct, you should try max_cstate.

for n starting at 3 and decreasing until the stound stops:
# echo n > /sys/module/processor/parameters/max_cstate

BTW. what model Thinkpad do you have?

The USB dependency is probably due to USB bus mastering causing
the system to "pop" out of C3 to snoop the USB DMA traffic.

On some older systems, this pops all the way to C0, and on newer
systems it transparently pops to C2 and returns to C3 w/o waking the OS.
You can get rid of it by disabling USB.  But it sounds like in the full-on case
you've got an issue even with USB disabled.  Or sometimes you can
bias the system to simply not enter C3 if it sees bus master traffic with

# echo 0xFFFFFFFF > /sys/module/processor/parameters/bm_history

Another thing to try building the kernel with CONFIG_HZ=100 -- which
is what a kernel for most laptops should be using in the first place.

cheers,
-Len

Re: Idle loop causes speaker whine/buzz (!)

[Henrique de Moraes Holschuh]

On Tue, 23 Jan 2007, Len Brown wrote:
> BTW. what model Thinkpad do you have?

I own a ThinkPad T43 with ATI graphics (I wish I had bought one with Intel
graphics, but they only had the crap screens on those), but I don't know if
Mike Perry has a ThinkPad at all.  It's just that whatever his laptop model,
these issues are probably generic ones.

Just FYI, the T43 runs 2.6.20-rc5+acpi-test without any new problems.  I
didn't try the acpi-acpica branch yet, though.

> The USB dependency is probably due to USB bus mastering causing
> the system to "pop" out of C3 to snoop the USB DMA traffic.

EHCI seems to not share the same issue.  OTOH, it draws a noticeable ammount
of power, so I end up rmmod'ing it (and uhci-hcd) when not using anything
USB.

> You can get rid of it by disabling USB.  But it sounds like in the full-on case
> you've got an issue even with USB disabled.  Or sometimes you can
> bias the system to simply not enter C3 if it sees bus master traffic with
> 
> # echo 0xFFFFFFFF > /sys/module/processor/parameters/bm_history

Hmm, this one is neat.  I will add it to the wiki.

> Another thing to try building the kernel with CONFIG_HZ=100 -- which
> is what a kernel for most laptops should be using in the first place.

Well, actually we should be using *tickless* kernels, and start a witch hunt
on userspace braindamage that wakes too often, but we are not there yet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Idle loop causes speaker whine/buzz (!)

[Mike Perry]

Thus spake Len Brown (lenb@kernel.org):

> On Tuesday 23 January 2007 16:00, Henrique de Moraes Holschuh wrote:
> > On Tue, 23 Jan 2007, Mike Perry wrote:
> > > Is there currently any way to disable busmastering or C3 transitions
> > > (without recompilation)? Or better: is it possible to make the system
> > > less eager to transition into C3 or otherwise reduce the frequency of
> > > these transitions? If I could just get the frequency of transitions to
> > > get out of the audible range, my life would be a lot better.
> > 
> > Read http://thinkwiki.org/wiki/Problem_with_high_pitch_noises, it may have
> > the answers.
> 
> Pretty good write-up.  It is correct, you should try max_cstate.
> 
> for n starting at 3 and decreasing until the stound stops:
> # echo n > /sys/module/processor/parameters/max_cstate

Ahh, very nice. The whine stops at n=2, which is consistent with my
hack of manually disabling busmastering (which kills C3). At least now
I have the option of peace and quiet vs longer battery life+annoying
whine. Probably a tolerable option for plane flights :)

> BTW. what model Thinkpad do you have?

I actually have a Compaq Presario V6000T (Intel version). I was afraid
to mention it because Compaqs are historically pretty junky and I
figured someone would just say "that's what you get for buying junk" :)
But aside from the whine the machine is really nice (slim form
factor, very light yet durable, standard components, etc). ACPI
suspend to RAM and such is also fully functional (at least with the
Fedora kernels).

> On some older systems, this pops all the way to C0, and on newer
> systems it transparently pops to C2 and returns to C3 w/o waking the
> OS.  You can get rid of it by disabling USB.  But it sounds like in
> the full-on case you've got an issue even with USB disabled.  Or
> sometimes you can bias the system to simply not enter C3 if it sees
> bus master traffic with
> 
> # echo 0xFFFFFFFF > /sys/module/processor/parameters/bm_history

Yeah, unfortunately this has no effect, even if I enable CONFIG_HZ=100
and CONFIG_HZ_100. What about that suspicious threshold structure in
the acpi_processor_cx struct? Is there any reasoning behind these
magic numbers in there for each state?

> Another thing to try building the kernel with CONFIG_HZ=100 -- which
> is what a kernel for most laptops should be using in the first place.

As an aside, maybe this config option should be moved to a boot
parameter? I don't think you're going to see distros shipping laptop
kernels vs desktop kernels anytime soon.. But it doesn't seem to make
any difference for me either way.



-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Re: Idle loop causes speaker whine/buzz (!)

[Len Brown]

On Tuesday 23 January 2007 19:33, Mike Perry wrote:
> Thus spake Len Brown (lenb@kernel.org):
> 
> > On Tuesday 23 January 2007 16:00, Henrique de Moraes Holschuh wrote:
> > > On Tue, 23 Jan 2007, Mike Perry wrote:
> > > > Is there currently any way to disable busmastering or C3 transitions
> > > > (without recompilation)? Or better: is it possible to make the system
> > > > less eager to transition into C3 or otherwise reduce the frequency of
> > > > these transitions? If I could just get the frequency of transitions to
> > > > get out of the audible range, my life would be a lot better.
> > > 
> > > Read http://thinkwiki.org/wiki/Problem_with_high_pitch_noises, it may have
> > > the answers.
> > 
> > Pretty good write-up.  It is correct, you should try max_cstate.
> > 
> > for n starting at 3 and decreasing until the stound stops:
> > # echo n > /sys/module/processor/parameters/max_cstate
> 
> Ahh, very nice. The whine stops at n=2, which is consistent with my
> hack of manually disabling busmastering (which kills C3). At least now
> I have the option of peace and quiet vs longer battery life+annoying
> whine. Probably a tolerable option for plane flights :)
> 
> > BTW. what model Thinkpad do you have?
> 
> I actually have a Compaq Presario V6000T (Intel version). I was afraid
> to mention it because Compaqs are historically pretty junky and I
> figured someone would just say "that's what you get for buying junk" :)
> But aside from the whine the machine is really nice (slim form
> factor, very light yet durable, standard components, etc). ACPI
> suspend to RAM and such is also fully functional (at least with the
> Fedora kernels).
>
> > On some older systems, this pops all the way to C0, and on newer
> > systems it transparently pops to C2 and returns to C3 w/o waking the
> > OS.  You can get rid of it by disabling USB.  But it sounds like in
> > the full-on case you've got an issue even with USB disabled.  Or
> > sometimes you can bias the system to simply not enter C3 if it sees
> > bus master traffic with
> > 
> > # echo 0xFFFFFFFF > /sys/module/processor/parameters/bm_history
> 
> Yeah, unfortunately this has no effect, even if I enable CONFIG_HZ=100
> and CONFIG_HZ_100. What about that suspicious threshold structure in
> the acpi_processor_cx struct? Is there any reasoning behind these
> magic numbers in there for each state?

doesn't matter -- this code is being re-written anyway to handle dynticks.
Further, even a very broken C-state promotion algorithm quickly finds
its way to the deepest available C-state on a completely idle system.
 
> > Another thing to try building the kernel with CONFIG_HZ=100 -- which
> > is what a kernel for most laptops should be using in the first place.
> 
> As an aside, maybe this config option should be moved to a boot
> parameter? I don't think you're going to see distros shipping laptop
> kernels vs desktop kernels anytime soon.. But it doesn't seem to make
> any difference for me either way.

There actually was patch for boot-time "dynamic hz" a while ago,
but it didn't make it upstream -- instead the compile time static HZ did.

Unfortunately, FC6 chose to move to 1000 HZ from 250 HZ --
which is pretty much the opposite of what you want to do for
battery life.  Though honestly, for many models it will not make
a significant difference -- including the one I used for an example
battery life system here:

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2006-bltk-paper.pdf

Also, other major distros, such as OS 10.2, are still available with HZ 250,

Further, as Henrique says, we should be cutting over to dynticks soon anyway.
(though we've been saying that for 6 months)

cheers,
-Len