Distribution: Gentoo Hardware Environment: Compaq Presario R3000 laptop, with Intel Pentium 4-m 2.4 Ghz I tried a few drivers of cpufreq with this laptop: 1. p4-clockmod: functioning well, gives me 8 different frequency levels, but warns that it's not capable of voltage modulation, and that for p-4-m i should use either speedstep-ich or acpi. 2. speedstep-ich: fails to load because it says the chipset is not supported. 3. acpi: loads fine apparently, and outputs the lines: cpufreq: CPU0 - ACPI performance management activated. cpufreq: *P0: 2394 MHz, 0 mW, 250 uS cpufreq: P1: 1596 MHz, 0 mW, 250 uS I'm guessing that it detects the right modes. But the power usage is shown as 0mW for both modes. I don't know what uS means... after loading the driver and setting governor to userspace (and also powersave) nothing seems to change. Also using apps like cpudyn, speedfreq and cpufreqd did not make the frequency change. Even though there's no errors in the logs. By the way I tried both with the vanilla kernel 2.6.8.1 acpi implementation and with the latest acpi patch from acpi4linux -20040816-26. If more information is needed please ask...
please post a lspci so that I can re-check that speedstep-ich can't work on your notebook. Also, run "x86info --mhz" both on "performance" and "powersave" governors activated. Also, please enable CONFIG_ACPI_DEBUG in your kernel config, and re-check for errors logged.
thanks for your reply. lspci is: 0000:00:00.0 Host bridge: ATI Technologies Inc Radeon 9100 IGP Host Bridge (rev 02) 0000:00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge 0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4347 (rev 01) 0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4348 (rev 01) 0000:00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 16) 0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349 0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c 0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342 0000:00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller 0000:00:14.6 Modem: ATI Technologies Inc IXP AC'97 Modem (rev 01) 0000:01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [ Mobility Radeon 9000IGP] 0000:02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 0000:02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 0000:02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 0000:02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) 0000:02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) 0000:02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01) 0000:02:07.0 USB Controller: NEC Corporation USB (rev 43) 0000:02:07.1 USB Controller: NEC Corporation USB (rev 43) 0000:02:07.2 USB Controller: NEC Corporation USB 2.0 (rev 04) would you like me to post lspci -vv too? I tried x86info -mhz, and recieved strange output: x86info v1.11. Dave Jones 2001, 2002 Feedback to <davej@suse.de>. Found 1 CPU Family: 15 Model: 2 Stepping: 9 Type: 0 CPU Model: Pentium 4 Xeon (Northwood) Original OEM Processor name string: Mobile Intel(R) Pentium(R) 4 CPU 2.40GHz Number of logical processors supported within the physical package: 1 1598.80 MHz processor (estimate). it gives me about 1.6 Ghz which is the low frequency option, on both powersave and performance, and also with userspace trying to change manually. What does that mean?
ok, i found out that when i boot i only load the acpi module, which includes the performance governor. this gives me 2.4Ghz according to x86info -mhz. as soon as i switch to powersave after loading it's module, x86info shows 1.6 Ghz. from now on, it stays on 1.6 Ghz, I couldn't switch back to 2.4 Ghz. neither changing back to performance module, nor unloading the powersave module helps changing back the frequency. even unloading the acpi driver and reloading it does not help. it stays on 1.6 Ghz until i boot. The other problems are that this is only according to x86info, all other /proc and /sys nodes are unaware of the change, and thus also the userspace daemons don't work well. Also I would like to know why when I load acpi it says 0 mW for both frequencies (I wish it was so... :) ). ACPI DEBUG is compiled into kernl but there's no more output than what I already gave earlier, maybe I need some command line option for the kernel? or other debug kernel option to be compiled?
the 0 mW entry has zero effects: it's an information provided by the BIOS which is not used in any code, and it is obviously incorrect in your notebook's BIOS. Can you disassemble the DSDT, please, and post the _PSS, _PCT and _PPC objects? Information on how to do that can be found at http://acpi.sourceforge.net
Created attachment 3762 [details] My disassembled DSDT - Compaq Presario R3000
I attached my disassembled DSDT. I can confirm that the lower frequency state I've been on since, 1.6 Ghz, is really working well, thermal shows much much lower levels, and battery lasts much longer. The problem of not being able to change it again to the upper performance state is still there, as well as the wrong info shown by cat /proc/cpuinfo and the cpufreq /sys files. Another problem that might be related is that cat /proc/acpi/processor/CPU0/power shows that C3 is not supported active state: C2 default state: C1 bus master activity: 00000000 states: C1: promotion[C2] demotion[--] latency[000] usage[06905110] *C2: promotion[--] demotion[C1] latency[018] usage[91996265] C3: <not supported> even though cat /proc/acpi/processor/CPU0/info shows that bus mastering control is available: processor id: 0 acpi id: 0 bus mastering control: yes power management: yes throttling control: no limit interface: no
C-states are independent, so I'd like not to handle it here. But as a sidenote: probably the BIOS did force C3 to be disabled using a too long latency; bus master control being available isn't the only requirement for C3. Will look into the other issues soon.
no PSS entry in the DSDT -- can you dump and decode the SSDT(s), if present, as well, please? Also, have you checked for a BIOS update yet?
Yes, I have upgraded the BIOS to the latest version. It didn't make any difference, I can change the frequency from 2.4 Ghz to 1.6 Ghz but cannot go back (for the record, the C3 state is still unavailable). I don't know how to "dump and decode the SSDT(s)", if you can provide me some instruction, or url to some instructions. I could not find any information until now. About the DSDT, is it possible that it needs some fix? I will post it again as it might have changed after the BIOS update. also do I need to try the command line option: acpi_os_name=["Windows something"] ?
Created attachment 3768 [details] dsdt.dsl - after BIOS upgrade I'm attaching again the disassembled dsdt after the BIOS upgrade, but I'm not quite sure there's any change in it. I tried recompiling it, and there's the same 1 error and 1 warning as before.
you need the pmtools package, available at http://acpi.sourceforge.net too. Then, follow the instructions at http://forums.gentoo.org/viewtopic.php?t=223411&highlight=ssdt in the posting by gspr on Mon Sep 20, 2004 12:53 pm.
Created attachment 3769 [details] SSDT.dsl Here is the disassembled SSDT, it includes a _PSS object, so I guess that's what you were looking for. Also I found out that I need to enable acpi debug layer and level through boot parameters or /proc node which I did not do. Do you want me to dump some of the debugging?
Then it looks like a BIOS bug.
you mean according to the SSDT? does the BIOS bug involve the missing C3 mode too or I should check that one seprately? What should I do? post a fix request the Compaq?
Sorry for being so imprecise before. It is my impression that the data provided by the BIOS in the ACPI SSDT table is somewhat incorrect: the transition to state P0 utilizing the data provided by the BIOSdoesn't succeed. BTW, what does "cat /proc/acpi/processor/CPU0/performance" say after a transition to a low power state?
I don't have a /proc/acpi/processor/CPU0/performance file. Is it not possible to fix those DSDT and SSDT errors? (I don't really understand what's the difference between DSDT and SSDT)
the DSDT errors are not causing the bug you're seeing here, so let's keep focused. Enable CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y in your config, then you'll have the file I talked about. if the subdirectory is named differently under /proc/acpi/processor/ it does not matter.
should i use the acpi debug options?
it isn't necessary to get that file to work.
before the change: state count: 2 active state: P0 states: *P0: 2394 MHz, 0 mW, 250 uS P1: 1596 MHz, 0 mW, 250 uS after the change: state count: 2 active state: P0 states: *P0: 2394 MHz, 0 mW, 250 uS P1: 1596 MHz, 0 mW, 250 uS well - i guess it's the same, so it's not aware of the change. the only tool that really shows me that the frequency is not 1.6 Ghz is x86info -mhz.
Can you use the acpi debug options both while - changing from 2.4 to 1.6 - changing back from 1.6 to 2.4 And copy the messages here. Along with cat /proc/acpi/processor/CPU0/performance before and after each change.
thanks for replying :) what acpi debug options do i need in /proc/acpi/debug_layer and /proc/acpi/debug_level? or just 0xFFFFFFFF?
You can use 0xFFFFFFFF for both. But remember to set it back to 0 soon after. Otherwise your log may be flooded with all ACPI messages :).
The whole process: laptop cpufreq # cat scaling_governor userspace laptop cpufreq # cat scaling_available_frequencies 2394000 1596000 laptop cpufreq # cat scaling_cur_freq 2394000 laptop cpufreq # x86info -mhz // 2397.69 MHz processor (estimate). laptop root # echo 0xFFFFFFFF > /proc/acpi/debug_layer laptop root # echo 0xFFFFFFFF > /proc/acpi/debug_level laptop cpufreq # echo 1596000 > scaling_setspeed laptop cpufreq # dmesg // **** Context Switch from TID 228D to TID 22E8 **** acpi_processor_perf-0229 [22E8] [219] acpi_cpufreq_setpolicy: ----Entry acpi_processor_perf-0114 [22E8] [220] acpi_processor_set_per: ----Entry acpi_processor_perf-0135 [22E8] [220] acpi_processor_set_per: Transitioning from P0 to P1 acpi_processor_perf-0155 [22E8] [220] acpi_processor_set_per: Writing 0x000000f6 to port 0x00b0 acpi_processor_perf-0177 [22E8] [220] acpi_processor_set_per: Looking for 0x00000001 from port 0x8027 acpi_processor_perf-0201 [22E8] [220] acpi_processor_set_per: Transition failed acpi_processor_perf-0215 [22E8] [220] acpi_processor_set_per: ----Exit- FFFFFFFFFFFFFFED acpi_processor_perf-0241 [22E8] [219] acpi_cpufreq_setpolicy: ----Exit- 00000000FFFFFFED laptop cpufreq # cat scaling_cur_freq 2394000 laptop cpufreq # x86info -mhz // 1599.86 MHz processor (estimate). laptop cpufreq # echo 2394000 >scaling_setspeed laptop cpufreq # dmesg // **** Context Switch from TID 228D to TID 22E8 **** acpi_processor_perf-0229 [22E8] [267] acpi_cpufreq_setpolicy: ----Entry acpi_processor_perf-0114 [22E8] [268] acpi_processor_set_per: ----Entry acpi_processor_perf-0129 [22E8] [268] acpi_processor_set_per: Already at target state (P0) acpi_processor_perf-0215 [22E8] [268] acpi_processor_set_per: ----Exit- 0000000000000000 acpi_processor_perf-0241 [22E8] [267] acpi_cpufreq_setpolicy: ----Exit- 0000000000000000 laptop cpufreq # x86info -mhz // 1599.55 MHz processor (estimate). so at the end of all this process I'm left on 1.6 Ghz, while the kernel doesn't even know it made it from 2.4 Ghz to 1.6 Ghz...
Created attachment 3772 [details] Test1 patch
OK. BIOS tells "transition to 1.6 GHz failed" to acpi/kernel and successfully changes it to that freq. The acpi driver never changes it back to 2.4 as it thinks the CPU is already in that freq. Can you try the same steps with test1 patch. With that you should be able to bump the freq back to 2.4 GHz.
OK, i will test the patch, but I'm using 2.6.8.1 should i try 2.6.9-rcX? (the patch applied cleanly so i will test it anyways in the meanwhile)
2.6.8.1 + this patch will work fine too.
ok, now with the patch x86info -mhz shows that it goes back to 2.4 Ghz. the other informations are still not showing correctly. I suppose the patch is a hack to workaround the BIOS bug?
It is a hack to determine if switching to 2.4. works and what should be in the SSDT instead. Please run the test script both ways and post the dmesg snippets here, then we can tell you, and you should be able to re-compile the SSDT and override the one provided by the BIOS.
Thanks a lot, so I understand I have to post the dmesg with DEBUG on again, this time with the patch applied? I'll do it right away... after some time... 2.4 Ghz -> 1.6 Ghz: **** Context Switch from TID 2F62 to TID 3075 **** acpi_processor_perf-0231 [3075] [2115] acpi_cpufreq_setpolicy: ----Entry acpi_processor_perf-0114 [3075] [2116] acpi_processor_set_per: ----Entry acpi_processor_perf-0137 [3075] [2116] acpi_processor_set_per: Transitioning from P0 to P1 acpi_processor_perf-0157 [3075] [2116] acpi_processor_set_per: Writing 0x000000f6 to port 0x00b0 acpi_processor_perf-0179 [3075] [2116] acpi_processor_set_per: Looking for 0x00000001 from port 0x8027 acpi_processor_perf-0203 [3075] [2116] acpi_processor_set_per: Transition failed. Status Found 0x00000010 acpi_processor_perf-0217 [3075] [2116] acpi_processor_set_per: ----Exit- FFFFFFFFFFFFFFED acpi_processor_perf-0243 [3075] [2115] acpi_cpufreq_setpolicy: ----Exit- 00000000FFFFFFED 1.6 Ghz -> 2.4 Ghz: **** Context Switch from TID 2F62 to TID 3075 **** acpi_processor_perf-0231 [3075] [2121] acpi_cpufreq_setpolicy: ----Entry acpi_processor_perf-0114 [3075] [2122] acpi_processor_set_per: ----Entry acpi_processor_perf-0137 [3075] [2122] acpi_processor_set_per: Transitioning from P0 to P0 acpi_processor_perf-0157 [3075] [2122] acpi_processor_set_per: Writing 0x000000f5 to port 0x00b0 acpi_processor_perf-0179 [3075] [2122] acpi_processor_set_per: Looking for 0x00000000 from port 0x8027 acpi_processor_perf-0210 [3075] [2122] acpi_processor_set_per: Transition successful after 0 microseconds acpi_processor_perf-0217 [3075] [2122] acpi_processor_set_per: ----Exit- 0000000000000000 acpi_processor_perf-0243 [3075] [2121] acpi_cpufreq_setpolicy: ----Exit- 0000000000000000
Hmmm. That means transitions from 1.6 to 2.4 happens cleanly. And this part of SSDT is broken. Package (0x06) { 0x0000063C, 0x00000000, 0x000000FA, 0x000000DC, 0x000000F6, 0x00000001 } It should be Package (0x06) { 0x0000063C, 0x00000000, 0x000000FA, 0x000000DC, 0x000000F6, 0x00000010 }
so it's only a small change 01 -> 10 in the end... where can i find instructions on using this to override the BIOS SSDT? should I also post the fix in acpi4linux, and send it to Compaq and request a BIOS update? Thanks a lot for the help!!
another question I forgot to ask, will the SSDT fix also the cpu freq report in the /sys /proc files?
yes, /proc [only if UP kernel] and /sys [always] will most likely show correct values then... unless there's another bug hidden, which I doubt.
thanks a lot... i still can't seem to find instructions on using the fixed SSDT in the kernel though. can you point me?
I found this through google. http://www.hoolehan.com/300mlinux/ (look for text under ACPI heading). Not sure whether this will work for SSDT or is it DSDT only.
no this one as well others i found only talk about using a custom DSDT... i found nothing about custom SSDT, is it possible at all?
I have not yet found any way to override the SSDT in the kernel. Do you know if it's possible at all? Is there any patch ready to allow this? The only things I found is about DSDT, which the acpi4linux patch allows too...
Use the patch from http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable and modify "DSDT" to "SSDT".
modify - you mean in the patch? --- linux/drivers/acpi/osl.c.orig +++ linux/drivers/acpi/osl.c @@ -215,13 +215,18 @@ return AE_OK; } +/**/static const +#include "/tmp/ssdt.hex" + acpi_status acpi_os_table_override (acpi_table_header *existing_table, acpi_table_header **new_table) { if (!existing_table || !new_table) return AE_BAD_PARAMETER; +/**/if (strncmp(existing_table->signature,"SSDT",4)) *new_table = NULL; +/**/else *new_table = (struct acpi_table_header *)AmlCode; return AE_OK; } is that right? I have to compile the fixed SSDT to ssdt.hex right? using iasl? it's the same like compiling a DSDT?
"Yes" to all your questions except the last one: I have never custom-built a SSDT, but I think it _should_ work.
well, I have tried several times to compile the SSDT in but with no success. compiling in the DSDT works though, but the SSDT returns errors in the kernel compile. the problem is in the ssdt.hex file that i choose instead of dsdt.hex. when i choose the dsdt one it's ok, but when i choose the ssdt it fails. maybe the ssdt should be compiled in a different way than the dsdt? i used iasl -tc ssdt.dsl
I'm sorry to disturb again, but I couldn't find any waay to test the fix of ssdt. I don't know how to compile it into kernel, because it gives me a lot of errors while compiling, which does not happen when compiling in a dsdt. can you help me again with this?
I still haven't found a way to check the fix of the SSDT in the kernel. I can't seem to contact the vendor with this issue either.
Try putting the stuff found in the SSDT directly into the DSDT at the appropriate point (i.e. under \PR), and recompile that instead. Maybe that will work... though I'm not sure...
I have no idea about DSDT language, and cannot find where and what from the ssdt I can put in the dsdt. Some help with this would be nice. Thanks
Created attachment 3904 [details] ssdt table stuck inside dsdt table Can you try the attached dsdt.dsl and make the changes that you want to make inside it, and then plug it into your kernel. You should be able to use this instead of BIOS supplied dsdt.
Thanks a lot. I tried this DSDT with fix you told me before on kernel 2.6.9, but the result is exactly the same. I can still get the frequency down to 1.6 Ghz, but it doesn't know about it and thus won't allow me to change it back. Only x86info -mhz shows me the correct frequency.
Hmmm. Interesting. Can you use the test patch again and send the messages you get (following similar steps u used before. My feeling is, it is somehow not using the DSDT that you provided...
If I understand correctly you want me to patch the 2.6.9 kernel with the test patch you sent before, and recompile the kernel again with the fixed DSDT, and see what errors I get this time. I hope I got it right, I'll do it and post it here.
Also I guess I need to enable Debug Statements, right?
Yes. Enable the debug statements too please.
Created attachment 3909 [details] Debug info from the test patch while changing frequencies Here is the debug info from the kernel
Oct 30 18:31:39 laptop acpi_processor_perf-0179 [28CA] [123] acpi_processor_set_ per: Looking for 0x00000001 from port 0x8027 Oct 30 18:31:39 laptop acpi_processor_perf-0203 [28CA] [123] acpi_processor_set_ per: Transition failed. Status Found 0x00000010 These two messages are exactly same as the message in #31. So, I don't think the changes to DSDT is taking effect. Probably it is still using BIOS DSDT in place of one you provided.
How come? in dmesg it says OS overides the DSDT from the BIOS. Anyway I can check it? By the way in kernel 2.6.9 i didn't find the custom DSDT option, so I #defined the two options directly in the source code of drivers/acpi/osl.c. I hope that's ok, it pointed to the fixed hex file.
The change you did in DSDT (changing 0x0..01 to 0x0..10) should be reflected in this debug output. Looking for 0x00000001 from port 0x8027 Here we are still looking for 1 in place of 10. You can double check, by changing it to some random value, and see whether you still see "Looking for 0x1" here....
Well I tried to change from 001 and 010 to 333 (?!) - how bad can that be. the result is tha same in the debug, still Looking for the 01 thing. Any idea why the DSDT is not really being used? I read somewhere that SSDT overides anything in DSDT, so maybe the bios SSDT overides the DSDT I provide?
Possible. May be you can comment out the code in ACPI, which looks for SSDT.
OK, I don't think I have any idea how to do this... is it safe at all? why can't the vendor just fix the bios
closing as will-not-fix b/c this is a BIOS bug. Check with the system supplier for a BIOS update. I've opened up bug 3774 to add the ability for easy SSDT overrides.
Thanks - overriding SSDT would be nice - I haven't succeedede in doing it yet