| View previous topic :: View next topic |
| Author |
Message |
alby.to
n00b
Joined: 29 Sep 2005
Posts: 12
Location: Italy - Turin
|
 Posted: Sun Oct 30, 2005 7:58 pm Post subject: Keeping a Turion cooler (Aspire 5024WLMi) |
 |
|
Hi!
I had asked (https://forums.gentoo.org/viewtopic-t-396283.html) for a way to force custom FID/VIDs to the CPUfreq driver, since the PSB table for my laptop is broken.
Nobody answered, but in the meantime I've found a way to hack the kernel CPUfreq driver to suit my needs.
Beware: this is VERY rough programming, I don't know shit about C. I didn't even bother to look for a "select case" construct, three IFs will do it, and after all, this code is executed only once. This forces these FID/VID pairs to the driver, ignoring any other ACPI-provided pairs. And these are the pairs that work for me, with a Turion ML-34, just remember that YMMV (changing the VIDs is easy, if your system gets unstable because of low voltages).
| Code: | powernow-k8: 0 : fid 0xa (1800 MHz), vid 0xe (1200 mV)
powernow-k8: 1 : fid 0x8 (1600 MHz), vid 0x10 (1150 mV)
powernow-k8: 2 : fid 0x0 (800 MHz), vid 0x16 (1000 mV) |
The default (and WRONG) BIOS PSB table gives:
| Code: | powernow-k8: 0 : fid 0xa (1800 MHz), vid 0x4 (1450 mV)
powernow-k8: 1 : fid 0x8 (1600 MHz), vid 0x6 (1400 mV)
powernow-k8: 2 : fid 0x0 (800 MHz), vid 0x16 (1000 mV) |
Since I'm not the only owner of this great (but not flawless) laptop I've decided to share this patch with the others... It's a quick'n'dirty way to hack the driver, maybe someone wil come up with a better hack... Or just better C constructs... 
Patch tested on linux-2.6.14-ck1
| Code: | --- linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-10-30 14:31:08.000000000 +0100
+++ patchlinux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2005-10-30 20:40:03.000000000 +0100
@@ -344,7 +344,7 @@
}
if (data->currfid == reqfid) {
- printk(KERN_ERR PFX "ph2 null fid transition 0x%x\n", data->currfid);
+ dprintk(KERN_ERR PFX "ph2 null fid transition 0x%x\n", data->currfid);
return 0;
}
@@ -746,12 +746,17 @@
u32 fid;
u32 vid;
- if (data->exttype) {
- fid = data->acpi_data.states[i].status & FID_MASK;
- vid = (data->acpi_data.states[i].status >> VID_SHIFT) & VID_MASK;
- } else {
- fid = data->acpi_data.states[i].control & FID_MASK;
- vid = (data->acpi_data.states[i].control >> VID_SHIFT) & VID_MASK;
+ if (i == 2) {
+ fid = 0x0;
+ vid = 0x16;
+ }
+ if (i == 1) {
+ fid = 0x8;
+ vid = 0x10;
+ }
+ if (i == 0) {
+ fid = 0xa;
+ vid = 0xe;
}
dprintk(" %d : fid 0x%x, vid 0x%x\n", i, fid, vid); |
The first change (printk->dprintk) avoids the ph2: null fid blah.... on startup...
Don't flame me for this horrible patch, it does its job for me and that's enough!
If you're asking what I mean with "it does its job", I can tell you this hack has lowered my CPU temp by 20+ °C under maximum load (from an insane 85-88°C to 65°C under kernel compile or mesa glxgears). The same results I have achieved under Win with RMClock. It's definitely worth the pain...
Bye!
_________________
* AthlonXP 3200+ - 1024M 333 - ABIT NF7 - GF 4200Ti 128 - 2x120G ATA133 - Cinergy 600 TV - SBLive! 1024
* Athlon64 3000+ - 2048M 400 - ASUS K8N-E Dlx - GF 6600GT 256 - 2x250G SATA - Audigy 2 ZS
* Aspire 5024WLMi - Turion ML-34 - 1024M - ATI X700 - 100G |
|
| Back to top |
|
 |
prymitive
Apprentice
Joined: 13 Jun 2004
Posts: 260
|
| Posted: Thu Dec 08, 2005 8:04 pm Post subject: |
|
|
| With RMClock I can have additional pstates: 800,1000,1200,1400,1600,1800Mhz (using 4-9 FID), maybe we could add does pstates with some hack and have much smoother cpu frequncy scalling? |
|
| Back to top |
|
|
alby.to
n00b
Joined: 29 Sep 2005
Posts: 12
Location: Italy - Turin
|
| Posted: Sat Dec 10, 2005 5:16 pm Post subject: |
|
|
I also use some additional P-state with RMclock, but I seriously doubt about their usefulness... P-state transitions take some time to accomplish, and if the cpu load is not steady, the continuous transitions generate some overhead and delay... Situations that keep cpu load to a steady middle level are quite rare. During a kernel compile or math computations you need 100% power, no need for mid cuts, and during normal usage the hard disk is the main bottleneck, few apps will benefit from, say, a P-state of 1400 MHz... If they need the power, they immediately get full frequency (and the occasional drop from 100% load, not long enough to step back to 800 MHz, decreases power consumption and heat anyway, to a not so smaller extent)... As soon as they don't need it anymore, we step back to the lowest state, with no performance loss...
You get most of the advantages of the powernow technology when you run at 800 90% (say) of the time; spending the remaining 10% at 1400 instead of 1800 MHz won't give any noticeable advantage, not in consumption nor in heat production... A 90% load 1400 MHz cpu doesn't suck much less than a 1800 MHz cpu loaded at 70%, each with their respective voltages... There is a difference, but so small I doubt it0s really worth the overhead and effort...
Just my 2 cents...
_________________
* AthlonXP 3200+ - 1024M 333 - ABIT NF7 - GF 4200Ti 128 - 2x120G ATA133 - Cinergy 600 TV - SBLive! 1024
* Athlon64 3000+ - 2048M 400 - ASUS K8N-E Dlx - GF 6600GT 256 - 2x250G SATA - Audigy 2 ZS
* Aspire 5024WLMi - Turion ML-34 - 1024M - ATI X700 - 100G |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
