Weird CPU noise

[bugsan]

i have a A7N8X-X
i have the "sound" under mandrake 10.1 (i've found this thread with google)

The setcpi works ! no sound anymore.
IMHO It's not a solution and it should be fixed in the kernel.

[mouse256]

IMHO It's not a solution and it should be fixed in the kernel.

I think so too, because the "make cpu idle calls" option in the kernel just doesn't work on the nforce2 mobo, linux always make these calls.
But I have no idea how I can make a bugreport or whateven

[g4c9z]

I don't have a laptop, but my desktop with an A7N8X-X motherboard had this problem and I found another way to fix it, by adding:

Code: Select all

append="no-hlt"

to the kernel parameters in /etc/lilo.conf (see man lilo.conf for exactly how to set it up). Then don't forget to run lilo to actually put it in your master boot record.

What this does is prevents the halt instruction from ever being executed, thereby forcing the CPU to always run at 100% capacity (which is what always happens in Windows, which is apparently why they ASUS never found the error in their motherboard). This means your computer will consume more power (as much as if it was using Windows), but I prefer that to an annoying noise.

This solution came from somewhere else on the Gentoo forums I think but I can't find that thread anymore.

[setagllib]

Kernel timer granularity will affect the maximum precision with which events can be scheduled and file/devicce/etc polls can be timed. This can sometimes make a visible difference in MPlayer (but not if you use the RTC, which you SHOULD) and WINGs-based apps since WINGs uses a stupid timing system based on timer ticks instead of real time (for instance, WindowMaker animations are much faster in 1000 than 100).

It is perfectly safe and certainly more efficient to run at 100 than 1000, but there is still a loss of precision for event polls and so on. Don't worry too much though.

I will soon have a D600 and report if I have the problem.

[mouse256]

...

What this does is prevents the halt instruction from ever being executed, thereby forcing the CPU to always run at 100% capacity (which is what always happens in Windows, which is apparently why they ASUS never found the error in their motherboard). This means your computer will consume more power (as much as if it was using Windows), but I prefer that to an annoying noise.
...

I don't understand that. In windows when my cpu is stressed it becomes way more hot as when it's idle, so it can't be running at 100% capacity all the time, or am I wrong?

[g4c9z]

Hmm, interesting. I don't properly understand it either, but my guess (and I'm just making this up) is that when Windows is always in an infinite loop (as is the case when you're not doing anything else useful), it's only using one component of the processor. When something more complex is happening, there's electricity going through all kinds of circuitry in the processor, hence more heat. But again, that's just my pseudorandom guess.

[mouse256]

I think it works another way. Normally when the cpu is idle, there happens nothing. But you can also send special idle instructions to the cpu, and when you do that the cpu will get even more colder.
But if this is true, there is a problem in the next theory:
*) Windows doesn't make the noise, so he isn't sending idle calls (Although I thought windows did it)
*) linux makes the sound, so it send idle calls. But when you disable idle calls in the kernel, the sound doesn't stop
I've read a lot of it on the internet, and as far as I can find the nforce2 mobo's make these idle calls from the bios, so the os must not do it. And that seems to be the reason why the "setpci" command solves the problem: it sets a bit so the bios won't make the idle call anymore.
But now my problem is: if that's right, and the bios makes the idle call, then why don't we have that sound in windows? I've also been busy in windows with setting that idle bit, but it makes no difference at all in windows. It seems windows and linux are doing something different, but I don't know what, and I either don't know which os is actually doing the right things...

[comcute]

I think it works another way. Normally when the cpu is idle, there happens nothing. But you can also send special idle instructions to the cpu, and when you do that the cpu will get even more colder.
But if this is true, there is a problem in the next theory:
*) Windows doesn't make the noise, so he isn't sending idle calls (Although I thought windows did it)

Yes it does, try disabling nforce audio drivers and you hear same annoying sound.

*) linux makes the sound, so it send idle calls. But when you disable idle calls in the kernel, the sound doesn't stop
I've read a lot of it on the internet, and as far as I can find the nforce2 mobo's make these idle calls from the bios, so the os must not do it. And that seems to be the reason why the "setpci" command solves the problem: it sets a bit so the bios won't make the idle call anymore.
But now my problem is: if that's right, and the bios makes the idle call, then why don't we have that sound in windows? I've also been busy in windows with setting that idle bit, but it makes no difference at all in windows. It seems windows and linux are doing something different, but I don't know what, and I either don't know which os is actually doing the right things...

Have you tried nforce official sound drivers?
If you load nvsound module into kernel, this annoying sound goes away.
With alsa, only way getting rid of it is setpci -s 0:00.0 6F.B=0F

[mouse256]

hmm, I doesn't hear the sound in windows when I disable the nforce drivers, maybe I'm doing something wrong, but I believe you it can

And installing the official nvidia drivers in linux, I would like to, but I didn't manage to get them working , maybe you have a step-by-step installation procedure?

[Zeddicus]

Okay -- slightly necromantic here, but I figure this might be helpful for someone.

I've found that adding "idle=poll" to the kernel arguments completely eliminates this sound on my Inspiron 8200 (even with speedstep/thermal/etc enabled). Hope it works for others!