[Fixed/Workaround] Asus G51J(x) CPU throttling investigation

cataphract...btw you proved me wrong. I never heard of laptop ones having that good of efficiency so i will admit i was dead wrong. I guess laptop ones have pretty good efficiency. Also great research and testing +rep

 

indeed... my tx850 only gets 80-85%. i know some non-modular can get in the 90's, but only at relatively low (maybe <60%) load. assumed laptop ones were about the same, maybe even less on a budget.

anyone who can open winhex and do search -> integer value, look through these.

Code:

11d8ac35-fb8a-44d1-098d-0b5606d321b9.sec0.compression.unpacked
1314216c-cb8d-421c-54b8-06231386e642.sec1.compression.unpacked
161be597-e9c5-49db-50ae-c462ab54eeda.sec0.compression.unpacked
16d0a23e-c09c-407d-4aa1-ad058fdd0ca1.sec1.compression.unpacked
2374eddf-f203-4fc0-0ea2-61bad73089d6.sec1.compression.unpacked
38871bf0-c64a-4896-e4b8-62d4850c7e68.sec1.compression.unpacked
441d8a48-a3e0-42af-bd89-842cf0487afa.sec1.compression.unpacked
899407d7-99fe-43d8-219a-79ec328cac21.sec1.compression.unpacked
8b5fbabd-f51f-4942-16bf-16aaa38ae52b.sec1.compression.unpacked
8c783970-f02a-4a4d-09af-8797a51eec8d.sec1.compression.unpacked
90cb75db-71fc-489d-cfaa-943477ec7212.sec1.compression.unpacked
a2de77bb-797d-4bb5-c480-19aeb8b5cd29.sec1.compression.unpacked
a3eaab3c-ba3a-4524-c79d-7e339996f496.sec1.compression.unpacked
a7c619ff-9a64-4a89-7b94-e7953e2427cb.sec1.compression.unpacked
bfd59d42-fe0f-4251-72b7-4b098a1aec85.sec1.compression.unpacked
cbc59c4a-383a-41eb-eea8-4498aea567e4.sec1.compression.unpacked
d16fb508-be35-437f-ca9c-2ea65f13d08d.sec1.compression.unpacked
e03abadf-e536-4e88-a0b3-b77f78eb34fe.sec1.compression.unpacked

going through all 104 briefly, these are probably the more probably ones to have what we're looking for.

edit: this made me chuckle a bit:
(in a7c-)

Code:

seg000:00001173 loc_1173:                               ; CODE XREF: seg000:00001175j
seg000:00001173                 pause
seg000:00001175                 jmp     short loc_1173

 

Now that is some useful code .

Thank you for your replies.

I'm still searching through the various files you mentioned, one thing I found interesting from looking through the files was in 11d8ac35-fb8a-44d1-098d-0b5606d321b9.sec0.compression.unpacked

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00011130                               0A 02 0D 47 4D 43 48            ...GMCH
00011140   20 54 75 72 62 6F 20 44  69 73 61 62 6C 65 64 20    Turbo Disabled 
00011150   66 72 6F 6D 20 54 42 41  52 42 20 6F 66 66 73 65   from TBARB offse
00011160   74 20 39 38 68 00 0D 52  41 57 00 0C 00 00 00 80   t 98h..RAW.....€
00011170   0A 00 0D 43 50 55 20 54  75 72 62 6F 20 44 69 73   ...CPU Turbo Dis
00011180   61 62 6C 65 64 20 66 72  6F 6D 20 54 42 41 52 42   abled from TBARB
00011190   20 6F 66 66 73 65 74 20  39 38 68 00 0D 52 41 57    offset 98h..RAW
000111A0   00 0C 00 00 00 80 0A 0A  0D 50 6F 6C 69 63 79 20   .....€...Policy 
000111B0   50 72 65 66 65 72 65 6E  63 65 20 66 72 6F 6D 20   Preference from 
000111C0   54 42 41 52 42 20 6F 66  66 73 65 74 20 39 38 68   TBARB offset 98h
000111D0   00 0D 52 41 57 00 0C 00  00 00 80 0A 02 0D 47 4D   ..RAW.....€...GM
000111E0   43 48 20 50 6F 77 65 72  20 4C 69 6D 69 74 20 66   CH Power Limit f
000111F0   72 6F 6D 20 54 42 41 52  42 20 6F 66 66 73 65 74   rom TBARB offset
00011200   20 39 38 68 00 0D 52 41  57 00 0C 00 00 00 80 0A    98h..RAW.....€.
00011210   00 0D 43 50 55 20 50 6F  77 65 72 20 4C 69 6D 69   ..CPU Power Limi
00011220   74 20 66 72 6F 6D 20 54  42 41 52 42 20 6F 66 66   t from TBARB off
00011230   73 65 74 20 39 38 68 00  0D 52 41 57 00 0C 00 00   set 98h..RAW....
00011240   00                  

Wish WinHex would allow Integer search over multiple files as it does text ones.

Back to searching,

Peter

 

11da8c- is the DSDT data; you can dump that to a (not very much more readable) decompressed/disassembled form with

Code:

acpidump -b -t DSDT -o DSDT.aml
iasl -d DSDT.aml

on linux. not sure about iasl on windows, but the data itself is in the ACPI registry key (hklm/system something). you can change the fan trip points here.

 

It's interesting, from my research the Intel docs state that the OS is in charge of the CPU Turbo Boost based on the values put into the BIOS, of which none can be changed by the end user (aside from being able to disable Turbo Boost entirely in some systems). The "CPU Turbo Disabled from" and "CPU Power Limit from" and so on make me think this might be where that data is stored, where the OS/Intel Turbo Boost driver checks things before throttling down Turbo Boost.

If you're able to do that conversion that would be great. I was just thinking about getting out one of my Linux CDs and booting to that and then copying over the file and command so on - but if you're already there and can post the file then that would save a lot of time.

Thanks a lot,
Peter

P.S.

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00010EC0                                        0A 00 0D 43               ...C
00010ED0   50 55 20 54 75 72 62 6F  20 44 69 73 61 62 6C 65   PU Turbo Disable
00010EE0   64 20 66 72 6F 6D 20 45  43 00 0D 52 41 57 00 0C   d from EC..RAW..
00010EF0   00 00 00          

CPU Turbo Disabled from EC 13 RAW (Blank)

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00010FF0                                     0A 00 0D 43 50              ...CP
00011000   55 20 54 75 72 62 6F 20  44 69 73 61 62 6C 65 64   U Turbo Disabled
00011010   20 66 72 6F 6D 20 54 42  41 52 42 20 6F 66 66 73    from TBARB offs
00011020   65 74 20 35 30 68 00 0D  52 41 57 00 0C 00 00 00   et 50h..RAW.....

CPU Turbo Disabled from TBARB offset 50h 13 RAW (Blank)

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00011170   0A 00 0D 43 50 55 20 54  75 72 62 6F 20 44 69 73   ...CPU Turbo Dis
00011180   61 62 6C 65 64 20 66 72  6F 6D 20 54 42 41 52 42   abled from TBARB
00011190   20 6F 66 66 73 65 74 20  39 38 68 00 0D 52 41 57    offset 98h..RAW
000111A0   00 0C 00 00 00     

.....

CPU Turbo Disabled from TBARB offset 98h 13 RAW (Blank)

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00010F40      0A 00 0D 43 50 55 20  50 6F 77 65 72 20 4C 69    ...CPU Power Li
00010F50   6D 69 74 20 66 72 6F 6D  20 45 43 00 0D 52 41 57   mit from EC..RAW
00010F60   00 0C 00 00 00                                     .....

CPU Power Limit from EC 13 RAW (blank)

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00011090                                  0A 00 0D 43 50 55             ...CPU
000110A0   20 50 6F 77 65 72 20 4C  69 6D 69 74 20 66 72 6F    Power Limit fro
000110B0   6D 20 54 42 41 52 42 20  6F 66 66 73 65 74 20 35   m TBARB offset 5
000110C0   30 68 00 0D 52 41 57 00  0C 00 00 00               0h..RAW.....

CPU Power Limit from TBARB offest 50h 13 RAW (Blank)

Code:

Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00011200                                                 0A                  .
00011210   00 0D 43 50 55 20 50 6F  77 65 72 20 4C 69 6D 69   ..CPU Power Limi
00011220   74 20 66 72 6F 6D 20 54  42 41 52 42 20 6F 66 66   t from TBARB off
00011230   73 65 74 20 39 38 68 00  0D                        set 98h..

CPU Power Limit from TBARB offest 98h 13 RAW (Blank)



Question: Could offset 50h be for DC limit and 98h be for AC limit?

 

.dsl, open in your favourite text editor.
unfortunately those strings don't show up. it would be interesting to see where those offsets point.

 

Thank you for that, looking it over now. Ya, I think it really would be.

I mean, could offset 50h be for DC limit and 98h be for AC limit (or vice versa)? Having such a limit and then subtracting 13W for the amount of power Turbo Boost should require would make sense imho.

Peter

P.S. As additional background, thinking back to the Dell case it makes sense to have two separate limits. Dell didn't seem to input the DC one right as people were able to get much better performance out of their CPUs while on Battery than while on AC until the 130W adapter + BIOS upgrade - so a few ended up burning out their batteries.

 

i'll try feeding the unpacked files direct instead of dumping, perhaps theres a little bit more in there.
those are only offsets, no real values yet. being accessible from the OS, they could run an increment function 90 times on 30 to obscure it.

 

Yep exactly, that's why I was careful to say "offset 50h be for" . Sounds good, thanks.

Peter

P.S. Down in the rest of the file I found what TBARB may stand for: Thermal Device Bar. It appears they may be using the power values to try to determine the TDP and set the Power Limit/Turbo Boost Disable points based on those.

 

I have no idea if I'm doing this right, but from the same file:

50h: 77
98h: 00

13 was the number given for comparison with that value in the above statements.

Peter

 

iasl recognizes the header, can't read the table. perhaps 16d0- (ACPI) parses them beforehand.

yea, i read that again a little too late

we're looking for mW values, as i doubt asus would do the throttling with floats. it would be too much of a waste performance-wise (and i don't see many, if any at all, floating point ops in the assembly so far). i'll keep my eyes open for a rounding, but if ACPI gives mW for battery it'll give mW for AC as well.

 

I hear you, but in this case we are examining the ACPI given by Intel (Intel ACPI Component Architecture) not the rest of the system. If this is code from Intel itself, which would make sense, then they could have the values as they like. It would be the Intel Turbo Boost Drivers that would be interpreting this data, and they may not want to trust the system's mW rating or not depend on all OEMs keeping one or the OS being able to get it to that level of accuracy - or they may just prefer to work in rounded Ws.

Peter

P.S. The reason I assume 13 is the # given for those limits is from the Hex to Dec conversion of 000D, as from the following examples:

I haven't done this sort of low level stuff for years - am I doing that wrong?

 

nothing wrong with your conversion, but 0D occurs before every string
i'm no compression expert, only had one lecture about it (and it was at 8:30 in the morning).

not trusting the OEMs would need a standard way of getting that number, and there's nothing in the EFI documentation about that. in any case, i'm starting with subroutines and checking xrefs hoping to get some sort of value (or pointer).

attaching the pgdown/c disassembly of ACPI.
afk class

 

Very true - thanks. That actually makes even more sense since then we can use the EC, offsets 50h and 98h to find the limits in each of these cases.

Peter

 

Re DSDT:

I spent about an hour the other day combing through it and I couldn't find anything to do with fan trip points, nothing that looked to me like a table of temperatures or speeds. I searched for values around 85-95 and now I've read stuff about DTS and other ways those numbers could be stored etc will go through again looking for a wider set of values.

BTW it's at

HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\PEGA\PEGANB\00000001

Guides as to how to do it & where to get the progs are googlable - equus to extract it (which it took me 10mins to realise HAD to be in C:\ACPI or it would do nuthin) then asl to disassemble.


My wet dream would be if someone could write a fan/temp control program like i8kfangui.

 

Wit another look, there's something that looks like something:

Lines 4175-4207 (I've put the decimal values on the left)

Code:

                Name(TIM0, Package(0x9)
                {
                    Package(0x4)
                    {
120                        0x78,
180                        0xb4,
240                        0xf0,
900                        0x384
                    },
                    Package(0x4)
                    {
35                        0x23,
31                        0x21,
16                        0x10,
0                        0x0
                    },
                    Package(0x4)
                    {
11                        0xb,
9                        0x9,
4                        0x4,
0                        0x0
                    },
                    Package(0x7)
                    {
112                        0x70,
73                        0x49,
54                        0x36,
39                        0x27,
25                        0x19,
16                        0x10,
13                        0xd
                    },

and it's all repeated again from Line 4895 onwards with what look like the same values.

"TIM0" sounds like it just has to have something to do with temps, and that last set of numbers look like the cascading list we're after...

Does the fan speed work on the usual CPU temp only? Or does it include some measure of GPU temp as it seems to me like anytime it gets to 95C in a game the fan spins up to highest. Drops to 91-92, spins down, rises to 95, repeat. I'll start playing with CPU temps onscreen as well and see what happens.

 

Interesting. It does look like the values are repeated twice, and identically each time. Could that be an effect of the dis-assembly, or would it be repeated in the original code? How can we determine what exactly things are pointing to in that other version of the code? Trying to put it all together is making my head spin - the only time I've ever done anything from this direction is hacking the buttons on my MP3 player 6 years ago.

I was going to ask this in the BIOS dis-assembly thread - but the big notice that it is for technical discussion only made me decide it might fit better here. Is this just the AMI BIOS from the Mobo?

If so then our future MXM upgrade chances might be worse, I can see a couple of mentions of:
"NVIDIA Corporation mis-match between VBIOS and GPU. System halt!!!" with what seems to be a Device ID check in "a062cf1f-8473-4aa3-9387-600bc4ffe9a8.sec1.compression.unpacked"and "a062cf1f-8473-4aa3-9387-600bc4ffe9a8.sec1.compression.unpacked"

I know it's tangential to the rest of the discussion, but I wasn't sure where else to mention it and I'm curious what the answer is, if these files are include the MXM chip's VBIOS as well as the rest of the system BIOS.

Still trying to make sense of things...

Thanks,
Peter

 

if you're interested in finding temps, look for something that would have to do with PCIE or THRM. that's where the temp values are from (GPU and CPU proximity). it won't be an in-plain-sight value for temps or fan RPM.

AMI or Phoenix, it's UEFI now.
both VBIOS and GPU are exchangeable, that looks like the error for a function that checks whether or not it has the right VBIOS (to prevent any damage from whatever might happen). it also tells us that the VB is in the system BIOS (can't remember what GUID it had).

it's there twice because it's defined twice in the source. no pointers in AML afaik. only direct code and some conditionals.

 

Thanks, exactly about the VBIOS being in the System BIOS, that's what I took from those statements as well. When you say that they are both exchangeable, what do you mean by that? Through some kind of dis-assembly of the System BIOS and assembling it back? Or is there a simple way to: Update the VBIOS in the System BIOS and have the Device ID check changed to match that of the new MXM module?

I was assuming it would make things much more complicated if the VBIOS is in the System BIOS rather than the GPU since it would not be individually exchangeable in that case, and therefore why it would make MXM changes more problematic.

Thanks,
Peter

P.S. By the way, about Turbo Boost, It seems there may be fixes for this in recent kernels, but I've read that for some current Linux distros the only way to get Turbo Boost to work in them was to completely disable acpi. Have you noticed that?

 

yea, only goes up to 1.6 on linux. that's my primary system both on work and mobile, disabling ACPI will probably make sure it doesn't last a single train trip.

having a look through the VBIOS data; one is for the GTS360M (starting at 0x19686 and ending at 0x25E8E, no checksum), the other is for the GTX260M (starting at 0x2849B and ending at 0x357DF, no checksum).

for the interested people, the GTX260M perf clocks are at 0x34C1D (core), 0x34C1F (shaders), and 0x34C21 (mem) in words. voltage table header = 4B 49 20 06 02 04 at 0x34D9D. it only has 2 entries, .95 and .90v.



this COULD mean that a g51j can be flashed on a g51jx.

 

Ok, now the timer starts - how long till someone with a Jx with BSOD problems tries flashing the J BIOS .

If completely disabling the ACPI enables Turbo Boost - if there was some way to test if the throttling is taking place or not in that state, could that tell us anything about where the limits are used/located or in how they are implemented?

Peter

 

of course. that would tell us if it's the system ACPI controlling it or not. i'll give it a go tomorrow maybe. currently i'm going through PowerManagement (8c7 and IntelligentPowerSharing (d16f-) hoping to find something that doesn't need an EEPROM to analyse.

i really see no reason why flashing the BIOS won't work. if asus went through the trouble of adding it in, something tells me it HAS to work.

 

That was my thought exactly - I just thought I might have been wrong since it didn't come up in your previous reply.

To confirm, to be absolutely sure, what G51J BIOS are you working from here?

I can see that ASUS may have used G51J's to prototype test the GTS360M with VBIOS - or to unify most of the changes and work from the G51Jx as their new base for the latest BIOS updates - but that if you flash the G51J BIOS it may not recognize the two new banks of RAM (and instead expect the HDD Controller) - otherwise I can't see there being a problem - but it would still be a bit of a risk imho.

Peter

 

207.T10, http://g51jbsod.wikia.com/wiki/ASUS_G51J-A1_0x124_BSOD#fix
i guess you can always say you thought it was for the g51jx as well. the BSOD is a pretty serious issue.

there's AMI code in that same a08- firmware collection from june or april, so they've definitely been reusing as much as possible.

edit: if it was a prototype, how did it get the BSOD issue? that has me puzzled. unless one of the devs is playing a cruel joke...

 

Ya that would make sense to them. I wasn't sure if we were working from that official 208 release or 207.T10. When you did the comparison between the last official one a couple days ago, that was between the 207 and 207.T10 versions? It might be interesting to also do a diff on 207.T10 vs. 208 - they may have cleaned things up in the 208 version for the official release and there could be fewer changes from 207 or none from 207.T10. It could be useful info to look at from any of those vectors.

Thanks,
Peter

 

207 and 207.T10 it was. if i have enough time on the train or between class in the morning i'll have a sum comparison and full diff on it.
6hrs of sleep here i come.

 

Same here - gn man

Thanks,
Peter

 

I had previously tried running without ACPI in windows and it didn't work (I had also tried ripping out the acpi modules in Linux by hand but that didn't work either). This time I'm running Linux 2.6.33 and booting with acpi=off. I'm pulling 151 watts from the wall EDIT: THIS IS WILDY INACCURATE. It's a constant 120W reading with my kill-a-watt. (I have misplaced my kill-a-watt, so this is a rough reading from my furman power filter, 126Vx1.2A) running 8 threads of mprime + 9 instances of glxgears. My unthrottling app is not segfaulting anymore; I read a constant 13 from the msr. Unfortunately I have no way of telling what the temps are, but anecdotally the exhaust is burning my hand. I am going to let it run for a while to see if it melts.

 

Whoa here's hoping it doesn't.

Here's the report I referenced earlier about Turbo Boost - since it is relevant I'll put his post here - it was also with a G51J but back in November - it also link to a bugzilla bug about support being added to the kernel as well as a couple of other threads about the issue - all Linux specific:

Reference: http://ubuntuforums.org/showthread.php?t=1321028

By the way, I'm not sure how but the Turbo Boost system had a hiccup after I rebooted after trying to down clock the GPU too low and my system BSODing a night ago. I'm not sure if it is related to available power, but it was overclocking via TB to 2.98GHz w/Extreme Turbo instead of just 2.84GHz and the results I was getting from SuperPi beat the benches on a stock i920QM.

 

It didn't. That figure from my furman is wildy inaccurate, I found my kill-a-watt and it's pulling a constant 120W. The tool for linux monitoring is called i7z, and this has not been an issue for some time now (although on certain lappys it is still a problem EDIT: apparently not -- here's the real bug and it says fix released: http://bugzilla.kernel.org/show_bug.cgi?id=15064). I linked it from the throttling wiki page under linux tools. My proggy for unthrottling finally did segfault, but it took a lot longer without acpi (I did say it was an ugly hack ).

Edit: BTW my readings were 2.4GHz clocks w/o ACPI (no throttling apparently). They drop down to 19-2100 MHz without mprime running (which is to be expected).

 

temps are ez. `acpi -t` for THRM/CPU and `nvidia-settings -q [gpu:0]/GPUCoreTemp` for GPU (if you have nvidia-settings).

 

The CPU temp is what I was concerned about, and it requires ACPI. Catch 22.

nvidia-settings reported the temp for the GPU.

Edit: I'll have to run this test with a real graphics bench because it only got to 81C with 9 instances of glxgears. There was a substantial amount of heat from the exhaust and it was from the CPU. Combined with a 120W constant load it will be interesting to see what happens. I have to resolve some broken dependencies for phoronix-test-suite and I'll report back.

 

that, is a very good point.
no-go with lm-sensors either.

the JX and J have different firmwares in them, so xflashing is a no as well.

204 -> JX 204
207 -> J 207.T10
208 -> J 208

 

btw i am trying to keep up with these posts but they are way above my heard. All I want to say is thanks for all the hard work. Sad that I can't help.

 

In my tests I was seeing some modes that were having intermittent Turbo Boosts up to 80*C before the fan cycled up - but beyond that a lot of them just stopped showing any signs of it kicking in at all. The only way I've been able to get the CPU clock up to the 2.98GHz Extreme Turbo mode it's capable of was to underclock the GPU way too low and cut power to everything else as much as possible. The fact that your overclock is only 2.4 GHz rather than the standard 2.8Ghz max overclock suggests that either the system does not feel it needs the extra power, or else it's not getting enough to deliver it (but the throttling is not preventing it from working at all, as it has been doing in my Windows tests).

By the way, when you say 120W is that a direct reading from the Kill-a-Watt meter?

Whoa, quite a lot of diffs. Wondering though if some of it might be the different name of the Mobo/BIOS version.

Thinking about the diffs and I thought something that would be really useful was the diff for the Dell BIOS from before they changed the throttling limit from 90W to 130W to correspond with the new PSU. The only change in the BIOS from A06 to the fixed A07 was "Enhance CPU Power Management" - so I thought it might be worth a try to see if there was similar Intel code in there to what we've been looking at.

Unfortunately, the BIOS is in a 5+mb wph file and the process for the UEFI BIOS of the G51J/Jx is very different and I found a bunch of tools that might read it - but in the end none of them actually worked. After about 5 hours of trying and a fairly big headache I'm giving up on it now.

Peter

 

comparing dell's is a good idea, and one i didn't think of. unfortunately they had a very different scheme than ours (alternate CPU/GPU, throttlestop+rivatuner lock worked). knowing where the change was wouldn't help us in this case either as the structure will be completely different.

to clarify those filenames in case anyone got confused:
204 = G60JX v204
207 = G60J v207.T10
208 = G60J v208

 

I hear you that it wouldn't be identical, but some of the Intel sub code could be very similar. The clock modulation modifier additional throttling would kick in if the 7x modulator throttling that we have been seeing was not enough to limit the power - which it often wasn't since the adapters were only 90W. However, with the 130W adapters, they updated the code to actually increase the limit from 90W to 130W - and we know that because people with 210W adapters are getting the same performance/power improvements as those with the 130W adapters (which are able to cover the power requirements at all stock clocks on the XPS 1645 - but almost no overclocking at all).

A couple of times people suggested looking into this and experimenting as we have been, but it never went anywhere unfortunately - if we can do this it will be big

Peter

 

By the way, I'm about to go to sleep but I was looking into the Dell issue a bit more to confirm what I've read and there are hundreds of replies a day in the various threads about this since Dell promised to send out the 130W adapters and issued the new BIOS fix. I was curious to see if anyone with a XPS 1645 and a 90W adapter had tried the new BIOS to see how much of an effect it had (if any) but so far no luck on that. Also still looking around for the original 210W tests, a lot of people discussed them there including some mentioning the results, but I can't seem to find the original data.

With only the 90W adapter the Dell users didn't have enough overhead to even charge the battery, let alone run extra USB devices while under heavy GPU + CPU such as playing a game - we at least have that extra power with the 120W being more than the limit, but we are still being very limited in our performance for both the stock CPU w/Turbo Boost and/or the GPU at overclock if the power requirements get even close to that level.

What I can say is people are reporting that instead of the 90W limit, with the new BIOS A07 they now appear to have a 110W limit - so they are still seeing throttling if they push the GPU and CPU, but just not as extreme. This would result in the sort of throttling we are seeing on the J and the Jx where they need to be running the GPU and CPU under load to see throttling (before all they had to do was run Prime95 on it's own and they'd see it).

There are actually 2 separate laptops that Dell has this problem with:

Dell Studio XPS 16 w/Core i7 720QM and ATI 4670 1GB and FHD Screen is a Studio XPS 1645.
Dell Studio XPS 16 w/Core i5 430M, Core i5 520M, Core i5 540M, or Core i7 620M and ATI 4670 1GB and FHD Screen is a Studio XPS 1647.

Dell decided (to this point anyway) that the XPS 1647 requires only the BIOS upgrade because the low end i7/i5 processor models use less power. The XPS 1645 models though definitely showed a large difference with the new BIOS only if they had the new adapter - and vice versa (new adapter with no new BIOS had little effect, unless you were also using ThrottleStop).

Therefore, Dell might have had a lower limit on the XPS 1647 laptops, below 90W or they found that raising the limit beyond 90W still let the system run to its maximum without burning the adapter. Or they may find that users are complaining as much as they were about the 1645 and they may have to replace those adapters as well. Time will tell.

If the TDP is anything to go by (which it probably isn't when comparing products from completely different competing manufacturers) then the TDP on the ATI 4670 @ 35W is a little lower than that of the GTX260M and the same as the GTS360M.

There was a thread titled: "S-XPS 1645 AC Power Throttle Issue Investigation" and here is the updated list of findings from there from before Dell started sending out the new adapters:

It feels like deja vu - though I still think from our tests that we have a 100W limit rather than just 90W - between this and the other passage I quoted in my previous message - we are definitely experiencing the same effects as them - right down to not quite trusting the OEM to fix things fully.

Peter

P.S. Here is the official post from one of the Dell Admins on the Direct2Dell Blog: http://en.community.dell.com/blogs/direct2dell/archive/2010/02/24/throttling-update-for-studio-xps-1645-customers.aspx "This Studio XPS 1645 throttling issue is a limitation related to the 90-watt adapter. The resolution is to update the system BIOS, and for some, replacing the 90-watt adapter with a 130-watt adapter." - I think this post could be a good thing to quote when discussing the issue with ASUS Techs if they do not believe that the issue is happening with other i7 laptops (users of Acer laptops are also looking into it). It also specifies that it is a BIOS and Adapter limitation requiring a 130W adapter for systems that are about as power hungry as our G51Jx and potentially less power intensive than the G51J. I think all in all, it can be a good official resource for us to mention, in addition to all the user tests and info we're discussing here.

 

waiting to see what groceries tries with measurng temps (stick it with a thermometer), because the acpi firmware is larger than all the others combined. could be as simple as changing a dword

nice post (even if it's as long as the morning paper ). i sent off another ticket to asus yesterday, as they never got me past low level support. i don't expect something other than reinstall-windows answer (stated twice i tried and it affects other OS's) but hopefully i'm wrong and it does get forwarded to someone who knows.

edit: the m15x had the cycling, my mistake.

 

bumping for importance;

sub3B2C and sub3B36 are hiding at the very bottom of PowerManagement. regular code/data/xref checks wouldn't pick it up, as it's too close to the end string. once those turned out to be subroutines, a bunch of ptr's are now actually calls. in short, these two read and write to a CPU MSR (rdmsr and wrmsr).

sub3B2C:

Code:

sub_3B2C
seg000:00003B2C                 rdmsr
seg000:00003B2E                 dec     eax
seg000:00003B2F                 shl     edx, 20h
seg000:00003B32                 dec     eax
seg000:00003B33                 or      eax, edx
seg000:00003B35                 retn
seg000:00003B35 sub_3B2C        endp

sub3B36:

Code:

seg000:00003B36 sub_3B36
seg000:00003B36                 dec     eax
seg000:00003B37                 mov     eax, edx
seg000:00003B39                 dec     eax
seg000:00003B3A                 sar     edx, 20h
seg000:00003B3D                 wrmsr
seg000:00003B3F                 retn
seg000:00003B3F sub_3B36        endp

part 2, we check xrefs and see what function in PowerManagement require a change

calling the MSR modifier function, MSR to be modified is 0x199 if a comparison ends up over some value?

Code:

seg000:00001488 sub_1488        proc near               ; CODE XREF: seg000:000014F5p
seg000:00001488                 dec     eax
seg000:00001489                 push    ebx
seg000:0000148A                 dec     eax
seg000:0000148B                 sub     esp, 20h
seg000:0000148E                 dec     eax
seg000:0000148F                 mov     ebx, ecx
seg000:00001491                 mov     ecx, 199h
seg000:00001496                 call    sub_3B2C
seg000:0000149B                 movzx   edx, word ptr [ebx]
seg000:0000149E                 mov     ecx, 199h
seg000:000014A3                 dec     eax
seg000:000014A4                 and     eax, 0FFFF0000h
seg000:000014A9                 dec     eax
seg000:000014AA                 or      edx, eax
seg000:000014AC                 nop
seg000:000014AD                 nop
seg000:000014AE                 nop
seg000:000014AF                 nop
seg000:000014B0                 nop
seg000:000014B1                 xor     eax, eax
seg000:000014B3                 dec     eax
seg000:000014B4                 add     esp, 20h
seg000:000014B7                 pop     ebx
seg000:000014B8                 retn
seg000:000014B8 sub_1488        endp

a 7 to be written? an ultra-efficient 8op loop to keep writing with ring0 priority (greater than OS/ACPI)? hmm...

Code:

seg000:00002235                 align 4
seg000:00002238                 dec     eax
seg000:00002239                 push    ebx
seg000:0000223A                 push    edi
seg000:0000223B                 dec     eax
seg000:0000223C                 sub     esp, 28h
seg000:0000223F                 dec     eax
seg000:00002240                 lea     ebx, loc_112D+1
seg000:00002246
seg000:00002246 loc_2246:                               ; DATA XREF: seg000:00001335�r
seg000:00002246                 mov     edi, 7
seg000:0000224B
seg000:0000224B loc_224B:                               ; CODE XREF: seg000:0000225E�j
seg000:0000224B                 movzx   ecx, word ptr [ebx]
seg000:0000224E                 dec     eax
seg000:0000224F                 mov     edx, [ebx+8]
seg000:00002252                 call    sub_3B36
seg000:00002257                 dec     eax
seg000:00002258                 add     ebx, 10h
seg000:0000225B                 dec     eax
seg000:0000225C                 dec     edi
seg000:0000225E                 jnz     short loc_224B
seg000:00002260                 xor     eax, eax
seg000:00002262                 dec     eax
seg000:00002263                 add     esp, 28h
seg000:00002266                 pop     edi
seg000:00002267                 pop     ebx
seg000:00002268                 retn

i smell something coming soon, hope it's not the smell of smoke going out the vent

edit2:
here's the first change i propose
in hex, 48 0B D0 E8 85 26 00 00 33 C0 48 turns in to 48 0B D0 90 90 90 90 90 33 C0 48 (edit offset 0x14AC) ---OR---
in assembly, seg000:000014AC call sub_3B36 into seg000:000014AC nop

edit3:
attached change + IDA db

edit4:
attached change for stock nvidia clocks

edit5:
IMPORTANT: THE FIRST MOD BREAKS ALIGNMENT. USE THE NEW ONE INSTEAD.

 

Awesome. That definitely looks convincing! Nice friggin job man.

But as I PM'ed you I don't entirely know how to put it back together. The first part is easy, since it's the opposite of the decompress step, but the rest I don't know yet.

 

if you do find anything, use the new change:
http://forum.notebookreview.com/attachment.php?attachmentid=45918&d=1267241832

replaced padding with nop's to restore alignment. the other one really would've bricked.

it's also a referenced subroutine, and compared to the other MSR modifiers it's isolated;

Code:

seg000:00001488 sub_1488        proc near               ; CODE XREF: seg000:000014F5p
seg000:00001488                 dec     eax
seg000:00001489                 push    ebx
seg000:0000148A                 dec     eax
seg000:0000148B                 sub     esp, 20h
seg000:0000148E                 dec     eax
seg000:0000148F                 mov     ebx, ecx
seg000:00001491                 mov     ecx, 199h
seg000:00001496                 call    sub_3B2C
seg000:0000149B                 movzx   edx, word ptr [ebx]
seg000:0000149E                 mov     ecx, 199h
seg000:000014A3                 dec     eax
seg000:000014A4                 and     eax, 0FFFF0000h
seg000:000014A9                 dec     eax
seg000:000014AA                 or      edx, eax
seg000:000014AC                 nop
seg000:000014AD                 nop
seg000:000014AE                 nop
seg000:000014AF                 nop
seg000:000014B0                 nop
seg000:000014B1                 xor     eax, eax
seg000:000014B3                 dec     eax
seg000:000014B4                 add     esp, 20h
seg000:000014B7                 pop     ebx
seg000:000014B8                 retn
seg000:000014B8 sub_1488        endp

95% sure this is what we're looking for. 270 pages of reading intel's docs (not counting actually programming, which my skillz won't be more than moral support), or something in EDK/TianoCore to let us construct our own BIOS... i think i'd rather go back to looking at the throttle function.

attaching a code-oriented IDB.

 

quick question while following this you guys disabled acpi and were able to max out gpu/cpu and the brick was at 120w. Also dell users got a 130 brick and still have throttling...so dell only increased the limit and still left them with a throttling laptop. If you guys do figure out how to fix it does that mean we need a larger brick and if so how big? What would we be dropping to buy a new one. Also what would be recommended.

EDIT:Also i can't rep any of you lol...otherwise i would. I have to spread the rep around so some day i will rep you again for all this great work

 

if we remove the limit set by asus, it will take as much power as the motherboard distribution can handle. if it's 200, it can handle 200. if only 120, then our mod won't change anything besides making an unstable throttling. keep in mind that at stock asus clocks + prime95 this thing will be a fireball, so there won't be a point in going more than 140-150.

(technically, we remove the throttle call and not the limit. the calculator will still be running AND/XOR in the back but not at such high priority and only during power drain greater than the trip point. since the throttle-reset has to be called as a parameter to the same arguement, and the reset happens a second or two after the power is available, the implication of it is negligible).

our MSR 0x199 subroutine is xref'd by

Code:

seg000:000014D4 loc_14D4:
seg000:000014D4                 add     [eax-7AB2BD15h], al
seg000:000014DA                 shl     byte ptr [esi+44h], 89h
seg000:000014DE                 or      eax, 2289h
seg000:000014E3                 inc     edx
seg000:000014E4                 movzx   eax, word ptr [edx+ecx*8+0Ch]
seg000:000014E9                 dec     eax
seg000:000014EA                 mov     [esp+38h], eax
seg000:000014EE                 jnz     short loc_14FC
seg000:000014F0                 dec     eax
seg000:000014F1                 lea     ecx, [esp+38h]
seg000:000014F5                 call    sub_1488
seg000:000014FA                 jmp     short loc_1518
seg000:000014FC ; ---------------------------------------------------------------------------
seg000:000014FC
seg000:000014FC loc_14FC:                               ; CODE XREF: seg000:000014EEj
seg000:000014FC                 dec     eax
seg000:000014FD                 mov     eax, dword ptr ds:loc_2270+1
seg000:00001503                 dec     esp
seg000:00001504                 lea     eax, [esp+38h]
seg000:00001508                 dec     eax
seg000:00001509                 lea     ecx, ds:0FFFFFF79h
seg000:0000150F                 dec     ecx
seg000:00001510                 mov     edx, edx
seg000:00001512                 call    dword ptr [eax+80h]
seg000:00001518
seg000:00001518 loc_1518:                               ; CODE XREF: seg000:000014FAj
seg000:00001518                 xor     eax, eax
seg000:0000151A                 dec     eax
seg000:0000151B                 add     esp, 28h
seg000:0000151E                 retn

still looking for a xref to that (structure fits). probably in unaligned code/data in the IDB i attached before. the bottom half of it was redone bad because of the nop mistake.

 

Wow, great work thalanix - all of this is going over my head as well I have to admit, I can understand most of the statements but not how it all fits together - so I'm very glad you do .

I tried to look into how to construct the BIOS a bit, it seems for UEFI standard that forum is the best resource - but if we are looking at AMI Aptio firmware in particular...? So we need to repack, recompress, re-bin and then finally do a final UEFI compress?

Basically though, that's the next step? To finalize these changes, re-assemble everything and then flash them on a G51J and observe and report?

Thanks,
Peter

P.S. Is this where you got the python files: http://marcansoft.com/uploads/insydehacks ?

P.P.S. I think I see that it came from http://forums.mydigitallife.info/th...re-merged.-Beta-testers-are-welcome.?p=196118 in particular...

 

Yes. That's where the python scripts came from. There is a utility called uefi_compressor.exe that is what is used to recompress the files. There's another one called EFIDC (edit: it's actually linked to in that thread). It's down to making sure the changes get inserted properly and then fixing the checksums at this point.

I'm also trying to find out if ctrl+home works on Aptio or what the process is for recovery.

I PM'ed thalanix with a whole bunch of details, but that's the gist of it. He did a hella sweet find!

Edit deuce: There is a reasonable amount of info about this mod. There is also a thread here about the same mod. The rest of the EFI mods with lots of detailed info for lappys seem to be for insyde not aptio. This one will be more than a byte tho.

 

Ya I was noticing almost all the threads were referring specifically to patching VT and used the vtenable.py to complete the next step.

It sounds like you guys have it handled though, so I'll watch and look forward to your results and hope the Jx will be fixable the same way

Thanks,
Peter

 

The Jx might be brickable the same way...

I am a total n00b when it comes to UEFI, so it could be some time before you hear anything from me (more uefi&intel docs to read, all linked from those threads). I don't want to take any blame for a brick. We should make sure the checksums are right, and although it's not necessary for checksums to match in order to flash with afudos, it might make for a very sad panda when the beast gets rebooted. So that's why I'm trying to figure out how the recovery works on aptio (if it's the same as regular AMI with ctrl+home and a floppy).

 

who wouldn't want a small house built of bricks that can double up as heating (not so much air conditioning) . it's possible that we indirectly edited out TurboBoost support, but i think that works at much higher timing than this r/w function. i already volunteered to do the testing on mine.

it might be worth it to wait until a BSOD fix for the Jx is out, the actual code for this isn't going to change and it should be relatively easy to find again as long as they don't try and hide it.

some more neat CPU related stuff, not related to throttling but still interesting:

Code:

seg000:00003B40                 rdtsc
seg000:00003B42                 dec     eax
seg000:00003B43                 shl     eax, 20h
seg000:00003B46                 dec     eax
seg000:00003B47                 shrd    eax, edx, 20h
seg000:00003B4B                 retn
seg000:00003B4C ; ---------------------------------------------------------------------------
seg000:00003B4C                 mov     eax, cr0
seg000:00003B4F                 dec     eax
seg000:00003B50                 and     eax, 60000000h
seg000:00003B55                 dec     eax
seg000:00003B56                 cmp     eax, 0
seg000:00003B59                 jnz     short locret_3B69
seg000:00003B5B                 wbinvd
seg000:00003B5D                 mov     eax, cr0
seg000:00003B60                 dec     eax
seg000:00003B61                 or      eax, 60000000h
seg000:00003B66                 mov     cr0, eax
seg000:00003B69
seg000:00003B69 locret_3B69:                            ; CODE XREF: seg000:00003B59j
seg000:00003B69                 retn
seg000:00003B6A ; ---------------------------------------------------------------------------
seg000:00003B6A                 invd
seg000:00003B6C                 mov     eax, cr0
seg000:00003B6F                 dec     eax
seg000:00003B70                 and     eax, 9FFFFFFFh
seg000:00003B75                 mov     cr0, eax
seg000:00003B78                 retn

cr0 = control register, http://en.wikipedia.org/wiki/Control_register
600- is a 1 in bits one and two, 0 elsewhere
9FF- is a 0 in bits two/three, 1 elsewhere

since groceries said he'd take care of the lego, i'll try and find our elusive fan trip points. since a lot of people already went through the DSDT table, i'll take a stab at ACPI. anyone who wants to catapult this forward, do some tests with furmark and prime95 while writing down at what THRM and GPU value the fan spins up.
(this means both GPU and CPU during each stress test, it could be either that trigger it)

this line can look familiar:

Code:

seg000:00004679 byte_4679       db 0Fh, 31h, 48h        ; DATA XREF: seg000:00000395o

in decimal: 15, 49, 72


some values, 70 T, 85 T, 82 G, 93 G (T = THRM, G = GPU)

 

another post i feel is bump-worthy.

while redoing the disassembly for bad xrefs/misalignment, i found this segment. 0x19A is the clock modulation register. it could be the next step of throttling. it's isolated from the 1AA/1A0/1FC writes, but close to the 0x199 write. logically, if the 199 write can/is be used as throttling then so can this. that also means if the 199 is _not_ for throttling, then this isn't either.

Code:

seg000:00001918                 dec     eax
seg000:00001919                 sub     esp, 28h
seg000:0000191C                 mov     ecx, 19Ah
seg000:00001921                 call    sub_3B2C
seg000:00001926                 mov     ecx, 19Ah
seg000:0000192B                 dec     eax
seg000:0000192C                 mov     [esp+30h], eax
seg000:00001930                 or      dword ptr [esp+30h], 10h
seg000:00001935                 dec     eax
seg000:00001936                 mov     edx, [esp+30h]
seg000:0000193A                 dec     eax
seg000:0000193B                 add     esp, 28h        ; DATA XREF: seg000:off_21F5o
seg000:0000193E                 jmp     loc_3B36
seg000:00001943 ; ---------------------------------------------------------------------------
seg000:00001943                 int     3               ; Trap to Debugger
seg000:00001944                 dec     eax
seg000:00001945                 sub     esp, 28h
seg000:00001948                 mov     ecx, 19Ah
seg000:0000194D                 call    sub_3B2C
seg000:00001952                 mov     ecx, 19Ah
seg000:00001957                 dec     eax
seg000:00001958                 mov     [esp+30h], eax
seg000:0000195C                 and     dword ptr [esp+30h], 0FFFFFFEFh
seg000:00001961                 dec     eax
seg000:00001962                 mov     edx, [esp+30h]
seg000:00001966                 dec     eax
seg000:00001967                 add     esp, 28h
seg000:0000196A                 jmp     loc_3B36

fairly standard stuff. read MSR, reset MSR loc, reset stack to a decreasing ax (program counter?), check alignment, do someting, set stack pointer to the MSR r/w sub, call the write. and it does this twice: first time it checks everything WITH bit 5, second time it checks for everything WITHOUT bit 5.

looks like it's after bit 5 in the modulation MSR. i don't feel like reading what that is, so instead i ran tests to see if clock modulation is a second-stage throttling method.

preliminary benchmarks say no, but i need someone to check more precisely if it does. something like running furmark (affinity to cpu0), prime95 (affinity to 2/4 with 2 threads), and doing a benchmark with wprime (cpu6), maybe plugging in a usb device or two.

http://i137.photobucket.com/albums/q228/HoldFire/cmod-base.jpg
http://i137.photobucket.com/albums/q228/HoldFire/cmod-f.jpg
http://i137.photobucket.com/albums/q228/HoldFire/cmod-ft.jpg

i see no harm in nullifying the write to clock modulation either. PowerManagement has no right to manage our clocks

edit: PowerManagement is also done by intel. if other notebooks have this exact throttle scheme, then this would make the most sense.
http://download.intel.com/technology/framework/docs/ACPI_0-91.pdf says power values come from ACPI, so disabling ACPI for groceries' probably disabled throttling.
attached the fully disassembled (almost perfect) module, and disassembled (almost perfect) ACPI module.

the full disassembly of ACPI shows another problem (or possibility, however you look at it):

Code:

seg000:000046AA ; ---------------------------------------------------------------------------
seg000:000046AA                 rdmsr
seg000:000046AC                 dec     eax
seg000:000046AD                 and     eax, 0FFFFFFFFh
seg000:000046B0                 dec     eax
seg000:000046B1                 shl     edx, 20h
seg000:000046B4                 dec     eax
seg000:000046B5                 or      eax, edx
seg000:000046B7                 retn
seg000:000046B8 ; ---------------------------------------------------------------------------
seg000:000046B8                 dec     eax
seg000:000046B9                 mov     eax, edx
seg000:000046BB                 dec     eax
seg000:000046BC                 and     eax, 0FFFFFFFFh
seg000:000046BF                 dec     eax
seg000:000046C0                 shr     edx, 20h
seg000:000046C3                 wrmsr
seg000:000046C5                 retn
seg000:000046C6 ; ---------------------------------------------------------------------------

look familiar? yea, that's asus' less efficient spin on r/w MSR subroutines. too bad they aren't xref'd, subs or locs. this makes our job a lot harder since we have no way of telling what calls them, or where they return to. only way to do this is to find it per-register. there are no definitions for 0x199 or 0x19A, meaning it could just be a stub of an interface for PowerManagement by intel.

another reason i say it's a stub is because of,

Code:

seg000:000049F6                 align 4
seg000:000049F8                 dd 3 dup(0)
seg000:00004A04                 dd 315353h
seg000:00004A08                 db 2 dup(53h)
seg000:00004A0A word_4A0A       dw 32h                  ; DATA XREF: seg000:00001194r
seg000:00004A0C                 db 53h
seg000:00004A0D byte_4A0D       db 53h, 33h, 0          ; DATA XREF: seg000:00001101r
seg000:00004A10                 dd 345353h, 54534F49h, 0
seg000:00004A1C aMg2l           db 'MG2L',0
seg000:00004A21                 align 4
seg000:00004A24 aMg2b           db 'MG2B',0
seg000:00004A29                 align 4
seg000:00004A2C aMg1l           db 'MG1L',0
seg000:00004A31                 align 4
seg000:00004A34 aMg1b           db 'MG1B',0
seg000:00004A39                 align 4
seg000:00004A3C aTopm           db 'TOPM',0
seg000:00004A41                 align 4
seg000:00004A44 aSio_dev_status:
seg000:00004A44                 unicode 0, <SIO_DEV_STATUS_VAR>,0
seg000:00004A6A                 align 4
seg000:00004A6C aSetup:
seg000:00004A6C                 unicode 0, <Setup>,0
seg000:00004A78 aXpress         db 'XPRESS',0           ; DATA XREF: seg000:00001126r
seg000:00004A78                                         ; seg000:00000459o
seg000:00004A7F                 align 10h
seg000:00004A80 aVme            db 'VME   ',0
seg000:00004A87                 align 4
seg000:00004A88 aVl             db 'VL    ',0
seg000:00004A8F                 align 10h
seg000:00004A90 aTc             db 'TC    ',0
seg000:00004A97                 align 4
seg000:00004A98 aPcmcia         db 'PCMCIA',0
seg000:00004A9F                 align 10h
seg000:00004AA0 aPci            db 'PCI   ',0           ; DATA XREF: seg000:000010FAr
seg000:00004AA7                 align 4
seg000:00004AA8 aNubus          db 'NUBUS ',0
seg000:00004AAF                 align 10h
seg000:00004AB0 aMpsa           db 'MPSA  ',0
seg000:00004AB7                 align 4
seg000:00004AB8 aMpi            db 'MPI   ',0
seg000:00004ABF                 align 10h
seg000:00004AC0 aMca            db 'MCA   ',0
seg000:00004AC7                 align 4
seg000:00004AC8 aMbii           db 'MBII  ',0
seg000:00004ACF                 align 10h
seg000:00004AD0 aMbi            db 'MBI   ',0           ; DATA XREF: seg000:000010CDr
seg000:00004AD7                 align 4
seg000:00004AD8 aIsa            db 'ISA   ',0
seg000:00004ADF                 align 10h
seg000:00004AE0 aIntern         db 'INTERN',0
seg000:00004AE7                 align 4
seg000:00004AE8 aFuture         db 'FUTURE',0
seg000:00004AEF                 align 10h
seg000:00004AF0 aEisa           db 'EISA  ',0
seg000:00004AF7                 align 4
seg000:00004AF8 aCbusii         db 'CBUSII',0           ; DATA XREF: seg000:000010A4r
seg000:00004AFF                 align 10h
seg000:00004B00 aCbus           db 'CBUS  ',0
seg000:00004B07                 align 4
seg000:00004B08 dword_4B08      dd 0                    ; DATA XREF: seg000:00001096r
seg000:00004B0C aIsairqmask:                            ; DATA XREF: seg000:00001083r
seg000:00004B0C                 unicode 0, <IsaIrqMask>,0

there is no CPU or MSRs in the code or definition blocks.