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

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

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

Sun Mon Tue Wed Thu Fri Sat

30
Tag Cloud
&
(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

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 :-)

Replacing Xanthe

After nearly five years of intensive use, the time has finally come to replace my trusty S270 laptop, Xanthe. Overall, I'm surprised that she held out as long as she did. There has been some defects along the way, but in the end I've managed to keep things pretty much working (where the most recent and most serious fix was to remove the laptop speakers and soldering the inverter cable, which got partly severed in the screen hinge).

However, since a few months, there is one issue that I can't seem to fix: The AC adapter plug doesn't seem to properly connect to the socket, making the battery switch between charging and not charging all the time (once per second or so). This had a great number of side effects, like keys on my keyboard getting stuck or making the keyboard stop working completely, making my network connection break, making my screen brightness change eratically and other stuff that makes me utterly and completely annoyed. I've made a detailed post on the s270-linux mailing list about that, if you're interested.

So, after a few months of on-and-off annoyance, I've finally decided to get a new laptop. It's sucky, since apart from this issue, Xanthe is still serving me well. On the other hand, it's utterly cool, since I just ordered myself a Thinkpad X201. It's a very durable and efficient 12" notebook (over 10 hours of battery life, according to Lenovo!). More details when I get the package (should be somewhere this week!).

Fixing laptop adapter and inverter cables

Recently I've been fixing up some critical defects in my MSI S270 notebook: My display stopped working due to a broken inverter cable and my power adapter switched on and off all the time due to a broken cable as well.

The inverter cable goes from the laptop mainboard to the inverter, which is below the display. On its way it passes the left hinge, which is exactly where it was broken. Apparently I'm not the only one having these kinds of problems with the S270. Some people suggest that the hinges are badly made causing these problems.

I've looked closely at the inverter cable and it even seems the cable breaks are caused by a tiny thread that is wrapped around the inverter cable to keep it together. Three of the six (IIRC) wires has broken and a few more had cuts in the insulation. The breaks were very clean and seemed to be exactly at the spot where the wrapping thread had cut into the insulation...

Anyway, I managed to solder the tiny wires back together again (using some extra wire to fill the gap). The cable did become bigger from this, so I had to remove the speakers and their cable to make a bit room in the hinge to fit the soldered cable in.

It has been working for a few weeks now, but I'm afraid the solder connection will break eventually again. In the meanwhile I've been trying to get a new cable, but it's pretty impossible to get at and MSI Netherlands refuses to sell me a cable. They say the want to use all cables they have for repairs, meaning I have to send my entire laptop to them and pay €80 - €150 for a repair I could have done myself (the part alone is usually €20 - €30...).

I'm still happy with the laptop, while it is working, but I won't be buying another MSI when this one finally breaks down for good...

My power adapter cable had also broken, switching on and off when I wiggled with the cable. The cable used to have two round "blocks" at the start and the end (ferrite rings to prevent interference). Over a year ago the cable broke near one, now it broke near the other one. I've removed both of them now and soldered the stuff back together, making it work again.

MSI S270 laptop no longer charging?

With no indication as to why, the battery light of my laptop started blinking red yesterday. Normally it is green when charging, red when nearly empty and off otherwise. It shouldn't be blinking, ever. But it did.

Turning off the laptop, reinserting the battery, leaving it out for a while, none of this helped to stop the light from blinking. Some closer inspection showed that when not connected to AC power, the battery was discharging and Linux could read out the status just fine. However, when connected to AC power, the battery would not charge, and the status would be "unknown"!

I tried swapping the battery with my old one, which worked just fine. This seemed to suggest that my battery had somehow got broken. Since I've only bought the battery a few months back, I was already dreading having to deal with MSI support yet again. To confirm that the problem was in fact with the battery and not my laptop, I put my battery in Brenda's laptop (who has the highly similar S271). There, it worked like it should, giving a fancy green light. However, when I put the battery back into my own laptop, all the problems were gone and it charged normally again...

I'm still not completely sure what happened, but it seems like the battery got into some state that my S270 couldn't fix, but the newer S271 perhaps could? Oh well, glad it's working again, now let's hope it won't break again...

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 ...

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.

BIOS upgrade to get DDR400

Recently, I've added an extra memory module to xanthe, my notebook. Originally, she shipped with 512 MB DDR400 (== 200Mhz) memory. I added 1024 MB DDR400. For some weird reason, this caused my memory to be clocked at 133Mhz instead of 200Mhz, even when both memory modules support 200Mhz. Removing either memory module makes the other module at 200Mhz again.

Tonight I was googling around for a fix for this problem, when I found that a new BIOS version was released (v6.70, while I was running v6.50). Since MSI does not seem to like changelogs, my only option was to just try. Easier said then done, since the supplied flash program needs dos to run. The recommended way for this is, as usual, "Make a dos bootable floppy and run the program". Not having a floppy drive severely limited my options here. So, I googled around and found the "ultimate boot cd", wich should be able to boot into DOS.

Trying the UBC (supplied as a 200M iso download) proved very handy. It provides a FreeDos and OpenDos installation (IIRC, the flash tool worked under OpenDOS, but not FreeDOS). Furthermore, a lot of testing utilities and hard drive tools are included on the CD. Nice to have lying around.

Anyway, updating the bios was succesful (though my laptop did a full powerdown when it was finished, I suspect this was a feature of the flash tool). I was unable to see directly if it also solved my problem, since the new BIOS does not show the memory speed anymore (which would be a very stupid way to 'fix' the problem). But, using Memtest86+ (also on the UBC), I found out my memory was correctly clocked at 200Mhz.

Dehibernating my linux worked, which I did not really expect and I experienced a significant speedup when dehibernating and especially deswapping Firefox. Yay!

Lastly, when I first bought my notebook, I promised to post pictures of her insides and a tutorial on dissassembling the S270. Just now, I've found a S270 disassembling guide by MSI themselves, so I won't bother anymore. I might publish the pictures anyway if I finally get my gallery plugin to properly work.

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.

# Background

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.

# ACPI

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)
{
0x00000640,
0x000055F0,
0x00000064,
0x00000007,
0xE0202A88,
0x00000288
},

Package (0x06)
{
0x00000320,
0x00001EDC,
0x00000064,
0x00000007,
0xE0202D80,
0x00000580
}
})


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)
{
0x00000320,
0x00001EDC,
0x00000064,
0x00000007,
//0xE0202D80, // 1000mV
//0xE0202E80,  // 900 mV
0xE0202F00,  // 850 mV
//0xE0202F80,  // 800 mV
0x00000580
}


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.