I have a Dell Latitude with a Core 2 Duo, and as such my processor constantly emits a VERY high whine while it jumps in and out of the C4 state. The only thing I've been able to find that fixes this is RMClock for Windows (does not run under wine). From what I understand, undervolting with linux-phc should eliminate the whine as well, but the guide on Ubuntu's site doesn't work (namely, it tells me to grab a kernel source package from apt-get that isn't there anymore).
Can anyone help?
FreeBSD has a way to set the lowest state. I set my lowest state to C1 and let powerd do its work (using both ACPI and powerd can cancel out the power saving effects!). Perhaps Linux has a way to do this too?
There's a way to do it by recompiling the kernel, but I want to make sure I use the proper kernel settings (I've never used Ubuntu before), so I was trying to follow the [outdated] tutorial. Blah.
Quote from: rabbit on March 30, 2008, 08:45:05 PM
There's a way to do it by recompiling the kernel, but I want to make sure I use the proper kernel settings (I've never used Ubuntu before), so I was trying to follow the [outdated] tutorial. Blah.
Shouldn't need to compile it since these states generally need to change when switching between battery or AC (i.e. C1 is lowest for AC, and C3 lowest for battery).
In FreeBSD, its changed with the 'sysctl' command effortlessly. It's also changed by devd when changed between AC or battery...according to whats in rc.conf of course :P
No luck with sysctl. The only thing I can find about changing it is the linux-phc kernel patch.
Bah! This is the only thing left I have to do before I can stick to Linux for good.
Passing max_cstate=3 to the kernel at boot results in a black screen with a blinking cursor line. Nothing can be done with that :\
Quote from: rabbit on March 31, 2008, 08:12:16 PM
Passing max_cstate=3 to the kernel at boot results in a black screen with a blinking cursor line. Nothing can be done with that :\
Nono, you want to set the min level...this way ACPI subsystem can't drop below the specified level to begin with.
EDIT: Well depends if "C4" is larger by number or smaller by power...
FreeBSD shows this:
hw.acpi.cpu.cx_lowest: C1
Try a FreeBSD LiveCD (e.g. FreeSBIE) and see if you can set hw.acpi.cpu.cx_lowest
You would do
sysctl hw.acpi.cx_lowest=C3
Quote from: nslay on April 01, 2008, 12:35:08 AM
Quote from: rabbit on March 31, 2008, 08:12:16 PM
Passing max_cstate=3 to the kernel at boot results in a black screen with a blinking cursor line. Nothing can be done with that :\
Nono, you want to set the min level...this way ACPI subsystem can't drop below the specified level to begin with.
EDIT: Well depends if "C4" is larger by number or smaller by power...
FreeBSD shows this:
hw.acpi.cpu.cx_lowest: C1
Try a FreeBSD LiveCD (e.g. FreeSBIE) and see if you can set hw.acpi.cpu.cx_lowest
You would do
sysctl hw.acpi.cx_lowest=C3
That's what I don't want! It's the processor switching between C4 and C3 that causes the whine. I want to disable C4 so it can't switch to it and whine.
Quote from: rabbit on April 01, 2008, 08:05:01 AM
Quote from: nslay on April 01, 2008, 12:35:08 AM
Quote from: rabbit on March 31, 2008, 08:12:16 PM
Passing max_cstate=3 to the kernel at boot results in a black screen with a blinking cursor line. Nothing can be done with that :\
Nono, you want to set the min level...this way ACPI subsystem can't drop below the specified level to begin with.
EDIT: Well depends if "C4" is larger by number or smaller by power...
FreeBSD shows this:
hw.acpi.cpu.cx_lowest: C1
Try a FreeBSD LiveCD (e.g. FreeSBIE) and see if you can set hw.acpi.cpu.cx_lowest
You would do
sysctl hw.acpi.cx_lowest=C3
That's what I don't want! It's the processor switching between C4 and C3 that causes the whine. I want to disable C4 so it can't switch to it and whine.
Right, and what the sysctl means is that it won't drop to C4 or better power saving mechanisms. It will operate only between C1-C3.
Thats why I made a note about what "min" means.
root@manbearnix:/home/spencer# sysctl hw.acpi.cx_lowest=C3
error: "hw.acpi.cx_lowest" is an unknown key
Quote from: rabbit on April 01, 2008, 09:54:13 PM
root@manbearnix:/home/spencer# sysctl hw.acpi.cx_lowest=C3
error: "hw.acpi.cx_lowest" is an unknown key
Offtopic:
DopefishMan Bear Pig Lives!
Quote from: rabbit on April 01, 2008, 09:54:13 PM
root@manbearnix:/home/spencer# sysctl hw.acpi.cx_lowest=C3
error: "hw.acpi.cx_lowest" is an unknown key
Quote from: nslay on April 01, 2008, 12:35:08 AM
...
FreeBSD shows this:
hw.acpi.cpu.cx_lowest: C1
...
You would do
sysctl hw.acpi.cx_lowest=C3
Try hw.acpi.cpu.cx_lowest?
root@manbearnix:/home/spencer# sysctl hw.acpi.cpu.cx_lowest=C3
error: "hw.acpi.cpu.cx_lowest" is an unknown key
I trust you got a FreeBSD LiveCD to try that out?
sysctl is mostly a *BSD tool. Linux has it, but its very limited.
Linux relies mostly on /proc for getting system information.
The big difference between sysctl and /proc is that most /proc nodes are read-only and it isn't common to see someone setting system features by doing 'echo "some" > /proc/thing'. Sysctl is designed for not only retrieving system settings, but also setting them ... hence, why you don't need to reboot your system to set the min C# state.
From a programmer's perspective sysctl() is awesome while /proc is awful...nobody should ever have to fopen(), fread(), and do string parsing to get system information.
And to re-iterate for anyone who missed the implications of this post: BSD is not Linux, Linux is not BSD...they aren't related in any way, except they both feel like UNIX.
I think they are related at least a little bit (http://www.debian.org/ports/kfreebsd-gnu/) :P
(Yes, I'm fully aware of what's wrong with that statement, I intended it for humor only).
Quote from: Chavo on April 02, 2008, 01:51:35 PM
I think they are related at least a little bit (http://www.debian.org/ports/kfreebsd-gnu/) :P
(Yes, I'm fully aware of what's wrong with that statement, I intended it for humor only).
Debian/kFreeBSD is not Linux, its the FreeBSD kernel with a ported GNU userland.
Quote from: nslay on April 02, 2008, 11:05:16 AM
I trust you got a FreeBSD LiveCD to try that out?
sysctl is mostly a *BSD tool. Linux has it, but its very limited.
Linux relies mostly on /proc for getting system information.
The big difference between sysctl and /proc is that most /proc nodes are read-only and it isn't common to see someone setting system features by doing 'echo "some" > /proc/thing'. Sysctl is designed for not only retrieving system settings, but also setting them ... hence, why you don't need to reboot your system to set the min C# state.
From a programmer's perspective sysctl() is awesome while /proc is awful...nobody should ever have to fopen(), fread(), and do string parsing to get system information.
And to re-iterate for anyone who missed the implications of this post: BSD is not Linux, Linux is not BSD...they aren't related in any way, except they both feel like UNIX.
Nope! I'm probably going to have to send in my laptop to Dell to get it fixed, so I don't think I'll be doing much with it until then.
Quote from: nslay on April 02, 2008, 02:49:41 PM
Quote from: Chavo on April 02, 2008, 01:51:35 PM
I think they are related at least a little bit (http://www.debian.org/ports/kfreebsd-gnu/) :P
(Yes, I'm fully aware of what's wrong with that statement, I intended it for humor only).
Debian/kFreeBSD is not Linux, its the FreeBSD kernel with a ported GNU userland.
Thanks for ignoring the disclaimer.