"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"

Current filter: »S270« (Click tag to remove it or click and/or to switch it.)

About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Sun Mon Tue Wed Thu Fri Sat
11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29          
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Reviving Xanthe somewhat

S270 notebook

I was prompted to write this post after I got an email from another S270 user, thanking me for all the info I posted about these machines. He was also having power supply issues, with all the same resulting troubles I had (keyboard stuttering, USB issues, etc.).

He said he fixed this by simply replacing the notebook power supply and all his problems were gone. Interestingly I had already tried that and it didn't work for me, so we were having different problems.

Another reason for writing this post is that I actually fixed my power supply issues a few months ago. I can't really remember what prompted me too look into it again, but this time I didn't have anything to lose - I wasn't really using Xanthe for anything anymore. I opened up the casing completely, took out the mainboard to properly access the underside.

The power connector felt like it was fixed to the mainboard pretty tightly, but I put my soldering iron to it anyway. I just let the solder reflow nicely.

To my surprise, this actually worked. The power connector now powers the laptop properly, without any blinking. I suspect that the solder in one of the contacts had split and caused a flakey connection.

So, Xanthe is still idling around in a cabinet somewhere, but at least she's now usable as a backup or LARP prop sometime :-)

0 comments -:- permalink -:- 22:20
And the saga continues....

As you might have read in my previous post, I have been vastly unimpressed by MSI's warranty department. Or actually, I have been actually been quite impressed by the amount of incompetence that they have managed to concentrate in that department. But, I digress.

A few weeks back, MSI managed to take weeks to not replace my hard drive. I have been complaining about this, and they offered that I sent them the faulty drive (again) so they could replace it. Yet they could not send me a new drive, before they had received the old drive, since "the system would not allow it". They would not, however, require me to send back my entire notebook again, as a courtesy. It's not like I could use it for anything but decoration without a hard drive (it does not support booting from an USB stick, I discovered after installing debian om my stick), but well.

See more ...

0 comments -:- permalink -:- 22:28
So much for MSI support....

I was going to write a nice piece about MSI support here, as soon as I got my notebook back from MSI. About their nice service (pick up and return with UPS!) even though they are a little slow-ish. About their nice battery warranty (minimal 80% of capacity after a year) and their flexibility in applying that warranty (I was a few days too late, technically) But, I've decided not too.

There are several reasons for this. First of all, my notebook HD broke in the first place. Not a nice thing to do, though I should probably blame WD for not making HD's that can sustain repeated writes resulting from hibernation in the same area of the disk.

It could also be because it took them nearly a week to respond to my service request when I complained about a bad HD (with complete smart status and error logs to back up my case). All I got back was a UPS label, but I reckoned it took them a while to fully read through my case and decide what to do with it. As it turns out now, it seems they didn't even read it and just needed 6 days to send me a UPS label.

See more ...

1 comment -:- permalink -:- 19:57
Linux-2.6.19 FTW!

For the last couple of months, I've been having issues with my Linux hibernation. I had it working from the start, but for some unknown reason, it ceased working as of kernel 2.6.16. For the past months I have been unable to upgrade my kernel, since I did not have enough time to find and solve the problem.

This was nasty, since the newer versions of my wireless network drivers require > 2.6.16, the wacom tablet drivers have a few new features in 2.6.18 and there should be support for my (built-in) SD card reader since 2.6.18 (really generic support for SD host controllers ). None of which I could use, since upgrading would break my hibernation (and I really can't use my notebook without hibernation).

Last week, 2.6.19 was released. Even though I couldn't find anything in the changelog that would fix my hibernation (I'm nearly done reading it), I decided to give it a try anyway. Well, waddayaknow? It worked right away! I have to admit that suspend and resume is slower than it used to be (5s vs 2s for the actual writing/reading to/from disk), but it at least it works.

Also, the generic SD card reader support worked straight away, despite a warning in my kernel log:

sdhci:slot0: Unknown controller version (16). You may experience problems.

So far, I've not experienced any problems, though I haven't really done any real testing yet...

Another weird side effect of this new kernel is the occurrence of APIC errors:

APIC error on CPU0: 40(40)

So far, there have been no ill effects apart from this message, so I'll just ignore it for now. It is typical however, that I get this error roughly every 1000 seconds. Oh well...

As an added bonus, 2.6.19 introduces "MSI laptop extras". This allows me to query the state of my WLAN/Bluetooth button and allows my to set the display brightness programmatically. Real nifty, though I'm not sure how to use it just yet...

Update: It seems that suspend code now no longer swaps out applications before writing the memory to disk. This means the actual writing takes longer but starts earlier. In particular it also means that after desuspending, I don't have to wait until firefox gets unswapped first.

0 comments -:- permalink -:- 20:14
Undervolting your AMD PowerNow notebook using Linux

I've previously mentioned that I've undervolted my MSI Megabook S270 notebook. I got a request about how exactly I did this, so I'll elaborate here.


Undervolting is modifying your hardware parameters in such a way, that the system CPU runs on a lower voltage that it is supposed to. Running on a lower voltage means the CPU uses less power and produces less heat, which are both wanted on a mobile system. Different laptops have different methods of undervolting. What I describe here should applies to AMD Turion64 processors (Which I have), but should also work for all other AMD processors with PowerNow support.

PowerNow & cpufreq

AMD PowerNow is AMD's technology for scaling CPU frequencies and voltages. How exactly the scaling itself is performed is not all that interesting, how to control it is. Linux has a special cpufreq driver for PowerNow processors, which exports its interface through /sys/devices/system/cpu/cpu0/cpufreq. Here you can select a governor which decides at what speed your CPU should run.

Hidden from the cpufreq interface (which only concerns CPU speed changes), the PowerNow driver also changes the CPU voltage when the speed changes. So, your CPU voltage is already automatically decreased whenever the CPU speed is lowered. Yet, we want to decrease it even further.


Since we cannot set the CPU voltage when scaling, only the frequency, how does PowerNow know what voltage to set? You might think that the CPU itself handles this, but fortunately this is not so. The PowerNow driver gets the information about the possible states and corresponding voltages from the system itself, through one of two means: ACPI and legacy BIOS.

The preferred way of retrieving this information is through ACPI and this might or might not work. For me, this didn't work (There were errors in my kernel logs with CONFIG_CPU_FREQ_DEBUG enabled). When ACPI does not work, the PowerNow driver uses some legacy BIOS call I don't fully understand to get its values.

So, we want to modify the voltage values the PowerNow driver finds. Since I didn't fully know how the BIOS thing worked, that wasn't the way to go. So I had two options:

  1. Hack/hardcode the voltage settings in my kernel
  2. Fix my ACPI and modify my ACPI table.

I settled for the last one, since that is nicer and a lot better when upgrading kernels.

Fixing ACPI

Some poking around with the kernel and its debug output, I found that the ACPI object (CPU1._PSS) holding the PowerNow information was not properly loaded by the kernel. Doing the decompile-and-recompile-with-Intel's-compiler trick, showed that the Intel ACPI compiler didn't like that _PSS ACPI object either. See my older post about how I fixed these compilation errors. After fixing these, the PowerNow driver properly gets its settings from ACPI.

With CONFIG_CPU_FREQ_DEBUG enabled, PowerNow properly reports the found settings (don't know if this was any different before fixing ACPI, I don't want to break my ACPI and reboot to find out).

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.4)
powernow-k8:    0 : fid 0x8, vid 0xa
powernow-k8:    1 : fid 0x0, vid 0x1c
powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0xa (1300 mV)
powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x16 (1000 mV)
powernow-k8: cpu0, init lo 0x808, hi 0x1
powernow-k8: policy current frequency 1600000 kHz
cpu_init done, current fid 0x8, vid 0x8

Part of fixing the ACPI table, is recompiling a fixed version and inserting it into the kernel source. Now, instead of getting the ACPI table from the system on startup, Linux uses your modified table. This means we can modify any value in the table as if the actual ACPI table was changed.

Tweaking PowerNow

Time to turn to find out how to read the ACPI table and find out which value to actually change. After searching a lot I found the "BIOS and kernel developers guide for Athlon 64 and Opteron". At page 278 they describe where PowerNow gets its information. From there I find that the CPU1._PSS ACPI Package contains a number of (unnamed) packages, one for every CPU State (Two in my case). Each packets contains 6 32bits numbers, which represent various settings. This is my original _PSS Package:

Name (_PSS, Package (0x02)
    Package (0x06)

    Package (0x06)

From the PowerNow specs we learn that every CPU state has a fid and vid, for Frequency ID and Voltage ID respectively. The frequency is calculated as 800 + fid * 100 (in MHz). The voltage is calculated as 1550 - vid * 25 (in mV). This means the frequency cannot go below 800MHz, and since the maximum vid value is 0x1e the minimum voltage is 800mV. I seem to vaguely remember that either the fid or vid can only be set to multiples of 2, yet I can't seem to find any hint of that in the specs now. I did find that the maximum supported frequency change in one go is 200MHz, but the kernel takes care of that, so we don't need to worry about this.

The actual vid is coded into the fifth value in the package, at bits 6-10 (Powernow specs page 280). This means you can increment the fifth value by 0x80 to decrease the voltage by 50mV. Below is the package from the ACPI table I use now, along with a few other examples of different voltages (// denotes a comment).

Package (0x06)
    //0xE0202D80, // 1000mV
    //0xE0202E80,  // 900 mV
    0xE0202F00,  // 850 mV
    //0xE0202F80,  // 800 mV

I've tried running as low as 800mV, but then my system seems to boot okay, but as soon as I login (type my password correctly), it powers off. This seems so predictable that you would suspect the voltage change to have this effect, but increasing the voltage back to 850 mV gives me a stable system that is slightly cooler and uses less power. I'll repeat the (very rough) benchmarks I made back then here (current values are for the entire system).

  • 800MHz, 800mV - Crash on startup
  • 800MHz, 850mV - ~980mA/39°C idle, ~1170mA/48°C load
  • 800MHz, 1000mV - ~1020mA/41°C idle, ~1330mA/50°C load

As you can see, the power savings are very little when the CPU is idle, but quite significant when the CPU gets busy (100% load, though still at 800MHz). I have so for only undervolted my 800MHz state, since I barely ever need all my 1600MHz. But since my CPU gets especially power hungry when it's really fully loaded at 1600MHz (up to 2500mA), I suspect that a lot of power can be saved here. If you try this and get it to work, do tell! And don't forget to mention the actual voltage you get it to run on.

Update: Youri Matthys has been experimenting with undervolting too, and has managed to make his Turion at 1600Mhz run on 1000mV instead of the default 1300mV. The power savings are even better then I'd have hoped for: Under full load the battery usage drops from around 2500mA to 1700mA.

9 comments -:- permalink -:- 22:58
New Toy: MSI Megabook S270

Anyway, about The notebook I ordered finally arrived a week and a half ago. I have been playing around with it during the last week, therefore I have not posted this earlier :-)

I rather like the notebook already. I have yet to name her, but she's cute, small, a little alternative (with an AMD processor instead of an Intel one) and gothic (Dressed in all black). It's a perfect fit in my backpack, but I still want to get one of those second skin notebook sleeves to protect the notebook from the other residents of my bag :-) I've ordered one at the the Mediamarkt, but I'm not sure if it will fit properly (My screen is 12" widescreen, which is a few cm wider than most 12" laptops).

Read on for specs, linux hardware support, ACPI tables & voltage optimization.

See more ...

8 comments -:- permalink -:- 13:36
Copyright by Matthijs Kooijman