TM 5530G with Turion ZM-87: thermal trip points too low

I've opened a new thread as kizwan requested, here is the original post that I wrote in his BIOS mod request thread: http://forum.notebookreview.com/acer/480992-acer-laptop-phoenix-bios-bios-mod-request-204.html#post7438854

 

I take a quick look to your notebook ACPI table & I found some Thermal Objects not in there. I'll look into it again later. I'll get back to you tomorrow or the day after tomorrow (I need to find some free time for this). For the meantime can you install linux on your notebook. Any linux is OK. No need to erase existing OS, just dual-boot with it. We'll need linux to test the modified ACPI table.

 

No need Linux to extract the ACPI Table just download RW-Everything.
Just some suggestion =).
Download the Portable Version to save yourself some install.

 

Linux is for testing the modified ACPI table later. It's not for extracting the ACPI table. I already have the ACPI table, extracted directly from BIOS.

 

First of all, I'd like to tell you kizwan how grateful I am that you're spending your free time on solving my problem .
BTW are you sure that you don't want me to upload anything (or you already had my laptop's ACPI table lying around there somewhere)? I'd be interested in how these trip points are stored: I'm assuming there are different settings for each type of processor (probably not)? I'm asking because my RM-70 always behaved nicely, even when I freshly bought the lappie when it tended to heat up to 72-74 degrees before I changed the thermal paste and undervolted it.

That's alright weinter, I'm a long time Debian user, but thanks for your suggestion!

 

Any progress on the ACPI tables?

 

Please test this in windows. Please make a backup of windows first before proceeding. Load this table using the asl.exe in command prompt (run cmd program as an administrator. disabled UAC if you're using Vista or Win 7):-

Code:

asl.exe /loadtable TM5530G_DSDT_Alpha01.aml

Then, reboot.

Changes:-

• Add required thermal objects (including passive cooling threshold).
• Set passive trip point temperature to 95.05 Celsius.

If the processor still throttling at lower temperature, I'm afraid there something else caused it. Might need to update the CPU microcode. I know how to update Intel CPU microcode but not AMD CPU.

 

Ok, here's hoping it'll work
I'll try it right away, and post the results.

 

Sadly, it didn't seem to work . I've run a cmd with administrative rights (BTW, isn't it enough to give it just that? Turning UAC off entirely is a bit of an overkill, isn't it?) and run the command you gave me => "Table overloading succeeded". Then reboot.
After that I did IntelBurn test again, and the same thing happened at 73-74 degrees.
Do you know someone who can update AMD processor microcode?

 

You can turn ON UAC back later. It's not that hard.

No. Try BIOS-MODS.

 

Right, but turning UAC on or off doesn't influence the result in this case, no?
Anyway, I've got some news: when booting back to Linux, I accidentally found out a little more about this phenomenon:
I ran "yes | md5sum" in a terminal, and that got both cores working on the highest p-state but with only around 50-60% core usage. This way the temperature steadily increased up until 78 °C without down-throttling!! The moment I started another instance of "yes | md5sum" to reach a 100% core usage, that's when it started to switch back to 600 MHz intermittently. What do you make of this behavior? If it's not temperature related, then what could it be?

 

Your modded DSDT table will not work with asl.exe, because the revision of the old table is the same as revision of this table. In the documentation that comes with asl.exe downloaded from MS, asl.exe overrides DSDT table only if revision number is greater than the table currently loaded. I took a look at your modded DSDT, and found that you DID NOT change the revision number.
Here:

Code:

DefinitionBlock ("TM5530G_DSDT_Alpha01.aml", "DSDT", [COLOR="Red"][B]1[/B][/COLOR], "ATI", "SB700", 0x00001000)

In the original BIOS, it is revision 1 too, so the asl.exe table overloading simply will not work , just like Blasku reported.
I have changed the revision number and uploaded the table again. See attached file. Blasku, try it again.

You also must make sure that new table is there after the reboot. Even if asl.exe reports success, that does not mean anything (ah, that is SO M$ ), and you could still be using your old table after reboot.

Look up different articles on how to stop throttling on Linux. It should be fairly straightforward, just a few commands.
Add CPU Frequency Monitor to your panel and set it to Performance. And then do some tests. See if that stops throttling

 

Thanks a lot ! It actually overloaded the DSDT table this time, I could tell because SpeedFan found 3 other sensors that "weren't there" before...
So I ran IntelBurn, and it throttled the cores down again . Same temperature (never goes above 75) too.
I tried setting both cores from userspace to performance in Linux, but at 74-75 degrees with 100% system load it manages to switch back to 600 again .
The only thing left that could be causing the problem is the microcode, right? Cause I'm absolutely sure that the Turion isn't faulty, it ran perfectly in the other laptop.

 

Thank you for the information. I'm not usually override DSDT in windows, so I don't know about this. I tried on my notebook before & I found the table always overrided when I do loadtable. When I removed the FAN devices from DSDT, the FAN will be "deleted" from Device Manager. When I add back, the FAN will be "added" in Device Manager. When I tested passive cooling threshold, I can see the changes. When I lower the threshold, the processor throttle down. When I increased the threshold, the processor won't throttle. All of this without changing the revision number. Because it always work for me, I didn't check the asl doc. (I also double check it with AIDA64.)

 

I've tried the acpi=off kernel boot parameter in Linux and it seems to be doing the trick, as far as I can tell watching only the temperature readings. When it's not down throttling, it seems that the highest temp it gets to is 78 °C.

 

I have never fixed the Thermal table before, but looking at ACPI documentation and DSDT table it seems like the throttling is defined in SSDT and not in DSDT in his particular machine. So I don't think that modding DSDT is going to fix the problem.

Blasku, can you please provide an RWEverthing (program) report with all the ACPI tables?
1. Load RWEverything
2. Press ACPI
3. Save all
4. You should have a file like ACPITbl.rw

Then just zip it and upload somewhere

 

The one defined in SSDT is P-States. Throttling also can happen if the passive cooling trip point is too low (which is defined in DSDT). That's what I'm trying to investigate which one exactly caused the problem. Usually on AMD processor throttling can be fixed with CPU microcode update. Well, good luck to you then because I don't have anymore idea.

 

Here it is, I hope it'll be useful.
-----------------------
So there really isn't anything helpful in the SSDT, not even in what I've uploaded? If there isn't, then it might be time for me to start a thread at bios-mods.com...
-----------------------
OK, so for anyone who's just reading this thread expecting a conclusion, I've started a thread at bios-mods.com here: Acer Travelmate 5530G CPU upgrade to Turion Ultra ZM-87 - thermal throttling

 

Bios-mods.com's CPU Support forum is 'silent' to say the least, because the admin there has some problems with his utils' compatibility with Win7 64bit and hasn't replied to any threads since the end of April. Because of that, I thought that I'd write here:
Since I recently had some spare time on my hands (I've been using Linux with acpi=off kernel boot parameter without performance issues), I started looking for ACPI debug messages whenever thermal throttling takes place.
acpi_layer and acpi_level are at full verbosity (both set to 0xffffffff), so it's quite difficult to distinguish between the messages, but if I constantly watch the last 25 lines of /var/log/messages (using `watch -n 1 tail -n 25 /var/log/messages`), then I notice something whenever the phenomenon takes place. I couldn't separate the relevant message completely from all the noise, but at the right moment I see some operand dumps happening. I think that these are mostly tied to the method "\_SB_.AMW0.WMCA", but I'm not sure (note that I'm using the original DSDT tables right now).
If I'd dig into this further, and try to pinpoint which function is being called, do you think that with this information, you could help me identify the real cause of the problem, kizwan? I hope I'm not asking too much, but I got the impression that you are familiar with the method names in my ACPI table...

 

I've gradually enabled certain components in ACPI's debug_layer: with ACPI_PROCESSOR_COMPONENT, ACPI_THERMAL_COMPONENT, ACPI_POWER_COMPONENT and ACPI_FAN_COMPONENT enabled, there were no debug messages at all. Once I've added ACPI_EVENTS, then a lot of redundant messages started appearing (of course ), but since there was nothing else enabled, I could see the pattern of these messages easily. So I've triggered the premature thermal throttling, and this is what got into the messages:

Code:

May 22 11:20:05 deblptp kernel: [ 1727.190954] **** Context Switch from TID ffff8801334aa210 to TID ffff88013767e630 ****
May 22 11:20:05 deblptp kernel: [ 1727.190955] 
May 22 11:20:05 deblptp kernel: [ 1727.190957]   evmisc-0550 [ffff88013767e630] [00] ev_release_global_lock: Released hardware Global Lock
May 22 11:20:05 deblptp kernel: [ 1727.191021]   evmisc-0125 [ffff88013767e630] [00] ev_queue_notify_reques: Dispatching Notify on [CPU0] Node ffff880137c02820 Value 0x80 (**Device Specific**)
May 22 11:20:05 deblptp kernel: [ 1727.191037]   evmisc-0125 [ffff88013767e630] [00] ev_queue_notify_reques: Dispatching Notify on [CPU1] Node ffff880137c02840 Value 0x80 (**Device Specific**)
May 22 11:20:06 deblptp kernel: [ 1727.805476] 
May 22 11:20:06 deblptp kernel: [ 1727.805481] **** Context Switch from TID ffff88013767e630 to TID ffff88013767bd50 ****
May 22 11:20:06 deblptp kernel: [ 1727.805487] 
May 22 11:20:06 deblptp kernel: [ 1727.805500] evregion-0452 [ffff88013767bd50] [00] ev_address_space_dispa: Handler ffff880137656f30 (@ffffffff811dd908) Address 0000000000001080 [SystemIO]
May 22 11:20:06 deblptp kernel: [ 1727.805727]   evmisc-0478 [ffff88013767bd50] [00] ev_acquire_global_lock: Acquired hardware Global Lock
May 22 11:20:06 deblptp kernel: [ 1727.805749] evregion-0452 [ffff88013767bd50] [00] ev_address_space_dispa: Handler ffff88013776c990 (@ffffffffa014e242) Address 0000000000000071 [EmbeddedControl]
May 22 11:20:06 deblptp kernel: [ 1727.806330] 

I hope this isn't just a usual p-state switch event message, then it's quite useless...

 

The "\_SB_.AMW0.WMCA" is ACPI object used & recognized by Microsoft Windows Management Instrumentation (WMI). I don't know much about it. You can read about it here if you want to know more. However I doubt it related to your problem. I'm strongly belief the problem you are facing right now will get fixed after updating the CPU microcode. You can see several example at BIOS-MODS.

 

So that's what it is, thanks !
BTW, while waiting for a response to my thread at bios-mods.com, I've found (and tried) this: OSRC: Microcode
It seemed that the microcode update has been successful with this method, but I'm not entirely sure since the problem still persists (probably the update still contained some default values that should be altered in my case). At least I've found a nice method of trying out microcode under Linux, all that is needed is to reattach the microcode module with modprobe.

 

Hi!
Nothing really on topic to report, just found something real interesting in my google searches. I still couldn't decide whether I should be pissed off, or have a good laugh about it. Check this out: Poor heating on TravelMate 5530G with Turion ZM-87 - Portable Devices
It's like I have several alteregos with poor Google Translator level English .
Seriously, does anyone have an idea what this is? Who profits from this kind of stuff?
The internet truly is a wonderful place...