Bug 3507

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