# DSDT for NVIDIA GeForce Go 6100 to reduce notebook heat

## funeagle

Hello,

If you have a NVIDIA GeForce Go 6100 with NVIDIA nForce Go 430 chipset chances are that your CPU power states are not working. This means that your CPU is draining your battery and will be quite hot because it cannot sleep even if it was designed to.

You can check if it is your case by these commands:

```
dmesg | grep "MCP51M" # NVIDIA nForce Go 430 chipset

dmesg | grep "power states" # do you have your power states enabled ?
```

The second command should output  *Quote:*   

> ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])

  and for that you need a proper DSDT section of ACPI defined. If you did not get anything then it means that either it is invalid or you have not properly configured your kernel.

If you have the proper output with a MCP51M (NVIDIA nForce Go 430) chipset, please please do send me your DSDT (Differentiated System Description Table) to end my many months suffering. To do this you need to:

```
cat /proc/acpi/dsdt > dsdt.dat # binary file

iasl -d dsdt.dat # will generate a dsdt.dsl text file
```

Please send me the binary (dsdt.dat) or post here the text (dsdt.dsl) file, however for the text file you will need to: 

```
emerge iasl
```

 to generate it if you have not installed it before.

Thank you very much!

----------

## dottore

I have an HP dv9040ea. dmesg tells me something about "MCP51M".  But I don't have any lines about power states. You say: "If you did not get anything then it means that either it is invalid or you have not properly configured your kernel."  So how can I find out about the reason? How should I configure my kernel? Or is your posting not applicable to my computer?

Thank you!

----------

## funeagle

dottore,

It is applicable to your model as well, however your DSDT might be slightly different than mine. First you should install acpitool, 

```
acpitool -c
```

 will give you a fair amount of information from which you will see what is enabled for you at the moment and what is not. The second tool I would recommend you is powertop, with powertop you can fine tune not even your kernel but even your applications to have the least power consumed (it is essential when you are running on battery).

Then you should follow the Power Management Guide: http://www.gentoo.org/doc/en/power-management-guide.xml

This will be also useful if you have DSDT problems: https://forums.gentoo.org/viewtopic.php?t=122145

I would appreciate if you could show me your DSDT afterwards, I could tell you if your section for the power states are correctly defined, I tried a section from INT430 chipset but it put my CPU in a deep sleep and slowed my notebook down by about 10 times, even when 50% it was in C1 state and 50% it was in C4 state the switching between the states made it extremely slow.

----------

## Monkeh

Random DSDTs won't even be remotely suitable for your machine. I have a working MCP51 however, so if you supply yours, I can have a look.

E: hm, or not.

----------

## dottore

I just read the other threads and articles.  ACPI is quite complex but interesting.  I think I configured my computer as suggested.

My 

```
acpi -c
```

 gives:

 *Quote:*   

>   CPU type               : AMD Turion(tm) 64 X2 Mobile Technology TL-56
> 
>   Min/Max frequency      : 800/1800 MHz
> 
>   Current frequency      : 800 MHz
> ...

 

And I posted my dsdt at http://pastebin.com/f17218d75

I know there are two warnings from the iasl compiler. Some other article suggests that these warnings do not explain the missing C states.

I'm curious what you can find out.

----------

## funeagle

dottore,

You have the same problem as I do, your _CST section is missing, most often it is defined in this section:

 *Quote:*   

>   Scope (\_PR)
> 
>     {
> 
>         Processor (CPU0, 0x00, 0x00001010, 0x06) {}
> ...

 

As you see {} it is empty for you as well. I have written ACER to send me a proper DSDT I had no reply, maybe you have a better luck with HP, or we will have to wait for a gentleman to share his one for "MCP51M".

----------

## Richie

I've this issue too. A HP dv2140eu laptop with turion TL-52. Is it possible that a BIOS update could help here? There have been quite a few releases since the one I have now: F.13 vs. F.34.

I wrote HP a support ticket about this issue, but I doubt they can help as I think they support windows only, when it comes to consumer hardware.

If I find a way to update that BIOS without windows and it works, I'll post the DSDT here.

----------

## dottore

Yesterday I did an update of my BIOS (using Windows). It's F.38 from june. They made quite a few changes. But the _CST sections are untouched.

So I also filed a support request to HP. We will see...

[Edit 2007-08-06]

After some conversation with HP no real new result has been reached. HP offers a BIOS with the given quality. Take it or leave it  :Neutral: Last edited by dottore on Mon Aug 06, 2007 1:56 pm; edited 1 time in total

----------

## Richie

Just a thought..

If this dsdt entry is chipset-specific rather than mainboard-specific, wouldn't it be possible to get relevant information from amd or nvidia? 

How much does it differ between implementations? Would it be possible to gather this entry from a few other chipsets that work, and somehow work from there to resolve this? Maybe look at nvidias previous chipset!?

Unless it's dangerous to the hardware I'd be willing to try this myself, as this is a serious issue for me.

Edit:

According to this post:

 :Arrow:  http://bugzilla.kernel.org/show_bug.cgi?id=7576#c9

 *Quote:*   

> AMD SMP machines do not support C2/C3. BIOS enters an enhanced C1E mode if all 
> 
> cores are set to C1.

 

I have not been able to find any other source to verify if it's true or not. AMD's site is just full of marketing hype and press releases, no real technical doc's there as far as I can see, what a joke   :Confused: 

Is there evidence that anyone actually has c-states working on a turion x2?

----------

## dottore

One more thought.

Woulnd't it help to simply code a HLT statement in case the ACPI does not provide any c-states?

If I remember correctly in old times when there was no ACPI only the HLT statement was available to tell the cpu that now work is do be done.

OTOH I already read somewhere that using the hlt statement with a new AMD processor does not save much energy. But perhaps it would be a little more than nothing.

----------

## Richie

@dottore:

I notice I have c0 and c1, whereas you have only c0, according to "acpitool -c"

```

  CPU type               : AMD Turion(tm) 64 X2

  Min/Max frequency      : 800/1600 MHz

  Current frequency      : 800 MHz

  Frequency governor     : ondemand

  Freq. scaling driver   : powernow-k8

  Cache size             : 512 KB

  Bogomips               : 1608.82

  Bogomips               : 1608.82

  # of CPU's found       : 2

  Processor ID           : 0

  Bus mastering control  : yes

  Power management       : no

  Throttling control     : yes

  Limit interface        : yes

  Active C-state         : C1

  C-states (incl. C0)    : 2

  T-state count          : 8

  Active T-state         : T0

  (cpu1 same as cpu0)

```

However no c-states are defined in dsdt.

This is my fadt, not sure what its purpose is, but it states that _CST is not available

```

[000h 000  4]                    Signature : "FACP"

[004h 004  4]                 Table Length : 00000074

[008h 008  1]                     Revision : 01

[009h 009  1]                     Checksum : 6D

[00Ah 010  6]                       Oem ID : "HP    "

[010h 016  8]                 Oem Table ID : "30B5    "

[018h 024  4]                 Oem Revision : 06040000

[01Ch 028  4]              Asl Compiler ID : "PTL_"

[020h 032  4]        Asl Compiler Revision : 000F4240

[024h 036  4]                 FACS Address : 3BF19FC0

[028h 040  4]                 DSDT Address : 3BF13228

[02Ch 044  1]                        Model : 00

[02Dh 045  1]                   PM Profile : 00

[02Eh 046  2]                SCI Interrupt : 0009

[030h 048  4]             SMI Command Port : 0000142E

[034h 052  1]            ACPI Enable Value : F0

[035h 053  1]           ACPI Disable Value : F1

[036h 054  1]               S4BIOS Command : 00

[037h 055  1]              P-State Control : 00

[038h 056  4]     PM1A Event Block Address : 00001000

[03Ch 060  4]     PM1B Event Block Address : 00000000

[040h 064  4]   PM1A Control Block Address : 00001004

[044h 068  4]   PM1B Control Block Address : 00000000

[048h 072  4]    PM2 Control Block Address : 00001484

[04Ch 076  4]       PM Timer Block Address : 00001008

[050h 080  4]           GPE0 Block Address : 00001020

[054h 084  4]           GPE1 Block Address : 00000000

[058h 088  1]       PM1 Event Block Length : 04

[059h 089  1]     PM1 Control Block Length : 02

[05Ah 090  1]     PM2 Control Block Length : 01

[05Bh 091  1]        PM Timer Block Length : 04

[05Ch 092  1]            GPE0 Block Length : 08

[05Dh 093  1]            GPE1 Block Length : 00

[05Eh 094  1]             GPE1 Base Offset : 00

[05Fh 095  1]                 _CST Support : 00

[060h 096  2]                   C2 Latency : FFFF

[062h 098  2]                   C3 Latency : FFFF

[064h 100  2]               CPU Cache Size : 0000

[066h 102  2]           Cache Flush Stride : 0000

[068h 104  1]            Duty Cycle Offset : 01

[069h 105  1]             Duty Cycle Width : 03

[06Ah 106  1]          RTC Day Alarm Index : 7D

[06Bh 107  1]        RTC Month Alarm Index : 7E

[06Ch 108  1]            RTC Century Index : 32

[06Dh 109  2]      Boot Architecture Flags : 0000

[06Fh 111  1]                     Reserved : 00

[070h 112  4]        Flags (decoded below) : 000082A5

                     WBINVD is operational : 1

                WBINVD does not invalidate : 0

                       All CPUs support C1 : 1

                     C2 works on MP system : 0

                   Power button is generic : 0

                   Sleep button is generic : 1

                      RTC wakeup not fixed : 0

                RTC wakeup/S4 not possible : 1

                           32-bit PM Timer : 0

                         Docking Supported : 1

```

Not sure if it's relevant, but I run 64bit kubuntu on this laptop.

----------

## dottore

@Richie:

How did you create the FADT-listing? I did not find a program to do it.

But looking at byte #95 in /proc/acpi/fadt I see a 0 - no _CST.

----------

## Richie

Same command/program as with dsdt disassembly, I guess it works for other *dt in /proc/acpi as well if you have any.

I managed to update my bios in a "magical" way, involving swapping harddrives and installing that other os.

The good news is that the two warnings I had earlier is gone. The bad news is that there is still no _CST section.

Edit:  After bios update I lost about 4-5 degrees Celsius, which makes me kind of happy, because that should mean energy consumption is lower, and that's the whole purpose..

Edit 2: After some use I notice that temperature drop is more like 2-3 degrees. HP responded that they don't support linux. (big surprise   :Rolling Eyes:  )

----------

## retroman

I figured there would be a stick posted in the amd64 section by now saying wether or not the turion64 x2 has c states.  Ive been messing around with the dsdt for a few weeks now with no sucess.....

----------

## funeagle

Richie,

I did not get a notification about replies, so sorry for coming back to you late.

Our CPU should support the C states: http://laptoplogic.com/resources/detail.php?id=48&page=4

Our chipset supports C states: http://www.nvidia.com/object/IO_34696.html

that is all we need to have a cool and quiet system.

I have contacted NVIDIA they said that they support only products which they sell directly so I should contact the manufacturer.

I am requesting a proper DSDT from acer ever since, but they keep playing dumb. They asked me to update the drivers and bios that was the only smart reply, the bios update changed my DSDT but the processor definitions are still empty. Other replies were like reinstall the system etc. they clearly dont know what they are talking about or just want to distract me from the problem.

I was so desperate that I studied the ACPI specification and found out there that in order to support the higher C states they HAVE TO do it trough the _CST section, which we are missing. For lower C states they could also use some registers but that is not the case http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf.

One more tip. you dont have to request support for Linux, DSDT should be defined for Windows too, and that is what windows probably uses. You could send your manufacturer the DSDT table generated from windows and ask for windows support! You can use   ASL Compiler v. 3.0.1  from http://www.microsoft.com/whdc/system/pnppwr/powermgmt/default.mspx. In Vista run a console (cmd) as an Administrator (otherwise it will not have permission to get it) and then do a 

```
asl /tab=DSDT
```

 you can find more in the ACPI in Windows Vista [WinHEC 2006] on the same page.

I am still hoping because I tried to hack my DSDT with the most common setting for both CPUs:

 *Quote:*   

> 
> 
> Processor (CPU0, 0x00, 0x00001010, 0x06)
> 
>         {
> ...

 

It made my notebook like 10 times slower, which is good because that makes it clear that the CPU sleeps a bit the sleep timing is just wrong. It kept switching between C0 and C4 only which is odd and in both states it remained about 50% if I remember correctly.

I think the best we can do is keeping the support lines busy for a proper DSDT from Acer/HP/Others. What I am expecting from them is a bios update where the _CST is defined.

----------

## funeagle

I would NOT recommend buying a notebook from ACER if you want to use Linux.

If you plan to, please consider rather paying a little more and buying from a manufacturer with real support. You will save yourself time, have less stress and headaches!

----------

