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).
Questions? Praise? Blame? Feel free to contact me.
My old blog (pre-2006) is also still available.
See also my Mastodon page.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 |
(...), Arduino, AVR, BaRef, Blosxom, Book, Busy, C++, Charity, Debian, Electronics, Examination, Firefox, Flash, Framework, FreeBSD, Gnome, Hardware, Inter-Actief, IRC, JTAG, LARP, Layout, Linux, Madness, Mail, Math, MS-1013, Mutt, Nerd, Notebook, Optimization, Personal, Plugins, Protocol, QEMU, Random, Rant, Repair, S270, Sailing, Samba, Sanquin, Script, Sleep, Software, SSH, Study, Supermicro, Symbols, Tika, Travel, Trivia, USB, Windows, Work, X201, Xanthe, XBee
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.
Anyway, about the notebook. It's powered by an AMD Turion 64bit processor, which is rather new. It has a modest clock speed of 1600Mhz (the Turion range goes up to around 2600Mhz) but it is a lot faster than katherina, my current workstation. The chipset powering the notebook is an ATI RS480 (or 482 perhaps) with an on-board ATI 200M video chip. It has three USB2 ports, a firewire port, headphone & microfone jacks, 10/100 ethernet port, on-board modem, VGA DSUB out, an SD card reader and a Cardbus/PCMCIA slot.
There is also a DVD-RW drive, the normal touchpad (with two fancy, but perhaps fragile, buttons) and a 12" wide glare display (1280x800). Lastly, I'm pretty fond of the full-size keyboard, which has all the alphanumeric buttons in the normal size, with the backspace, enter and backslash buttons in the correct layout.
After toying around for a while in the pre-installed windows XP home environment, I burned a Debian GNU/Linux DVD and spent a trip from Enschede to Harderwijk installing linux. As expected, getting all the hardware to work with linux was not so trivial. I have not yet managed to make everything work properly, but I'll get there. Very helpful were reports of other people owning the same notebook, describing problems and solutions. Therefore, I will do the same thing here.
First, the easy stuff. Getting my network card to work was trivial: It's a Realtek 8101 chip, which works with the standard 8139too kernel driver. Also, the DVD burner burns DVD's out of the box using growisofs. I haven't tried burning CD's yet, though. The driver for the IDE chipset is also in the kernel (atiixp) but it also works fine with the generic driver I believe.
Getting sound to work cost me some more time, though it was not less trivial. ALSA contains a driver for the onboard ATI IXP AC97 sound card (snd-atiixp). I had seen a few reports of people claiming that the on-board speakers would not work until they used ALSA debugging to set some register to some obscure value. Since I experienced the same, I tried their approach to no avail. Also, the headphone out did not seem to be working either. After a bunch of debugging I gave up for the day and it was not until the next day that I found my problem: I had turned down the volume too much :-S
ALSA also contains a driver for the modem: snd-atiixp-modem. I have not tested if it works, I might if I get bored sometime in the future.
The notebook does not contain a INPROCOMM 2200 as reported by other people (see links below). Instead it contains the Ralink 2500 (or 2560 actually), which has an opensource driver available. Ralink appears to be an OS friendly company since they have released their drivers under GPL and assist the maintainers of those drivers.
To skip to the conclusion: I have not yet managed to get wlan working. There are a few versions of this driver, since they used to have different rt2400 and rt2500 drivers, but they merged them (together with another another IIRC) into one driver: rt2x00. The rt2500 driver does nothing for me, beta3 and cvs versions of the rt2x00 can detect visible networks, but not associate. I have not yet tried this on a "simple" access point without encryption or with standard encryption, but only on our specific (802.1x authenticated) university network.
I'll not go into more details right now (I will do so when I continue my debugging), but for now, this just doesn't work...
The notebook contains a fancy 4-in-1 cardreader, but there does seem to be any support for it. The device is an O2 Micro OZ711M1, a cardbus connected cardreader. It seems there are no linux drivers for this device (yet). I might investigate this one further in the future.
The video is provided by the on board ATI Express 200M chipset, with up to 128MB shared memory. Since I won't be gaming much, I've left the shared memory set to 64MB. I might turn it down a little even.
I have not yet tried installing the proprietary ATI driver, which should support direct rendering and OpenGL. I am now running on the open source "radeon" driver, which is shipped with Xorg. It performs nicely, but occasionaly makes the screen "flicker" for an instance (hardly noticable).
The bluetooth adapter in the notebook is attached through USB. You need to press the WiFi/Bluetooth button to turn bluetooth on (as opposed to WiFi, which is always on). When you press the button, a new USB device pops up as if you had just connected it. I have not looked at driver support for this yet. The device identifies itself as 0db0:a970 ("Micro Star International"). Since bluetooth is cool, I'll look into this soon.
The kernel seems to detect firewire fine, but I have no fireware devices to do any testing.
My USB ports are now working, but only in USB1 mode. At first, I couldn't get
USB working at all. There seemed to be some kind of irq problem, and passing
the irqpoll
kernel option at boot did not fix this as some other people
suggested. Simply disabling USB2 support (ehci-hci) solved the problem, so I
can at least use my mouse, keyboard and memory stick. This still needs fixing
sometime.
A few other people with this notebook claimed that the system clock ran twice
as fast as it should. This turned out to be the case for me too. It appears
the APIC (Interrupt Controller IIRC) somehow triggers each timer interrupt
twice. But instead of passing the noapic
option to the kernel as suggested
by some, I found that passing noapictimer
worked just as well. Since I
presume the APIC actually does something useful, I like leaving it on :-)
This is common problem among notebooks and PC's in general: The ACPI table is broken. The ACPI tables describes what hardware is present on a system and how to use the hardware. ACPI is sort of a programming language, with its own specification of how the code should look.
A lot of notebooks, however, contain an ACPI table that is not according to the specification. Nearly all of those ACPI tables have been not been compiled with the industry standard Intel compiler, but with the broken Microsoft compiler, which happily compiles incorrect code. Not surprisingly, Windows does not seem to care much about the ACPI specification either and generally works. On the other hand, it seems that Windows XP starts to break on some broken ACPI tables, so hopefully that'll improve.
Anyway, my ACPI tables is broken. The easiest way to find out is decompiling and recompiling it using the Intel compiler as follows:
# Export raw ACPI table from the BIOS
cat /proc/acpi/dsdt > dsdt.dat
# Decompile into dsdt.dsl
iasl -d dsdt.dat
# Recompile
iasl -tc dsdt.dsl
Doing this gives me three errors:
dsdt.dsl.orig 1256: Package (0x06)
Error 1045 - Initializer list too long ^
dsdt.dsl.orig 2760: C0E0, 8,
Error 1026 - ^ Access width of Field Unit
extends beyond region limit
dsdt.dsl.orig 2761: C0E1, 8
Error 1026 - ^ Access width of Field Unit
extends beyond region limit
I am not sure these errors actually matter, they might not be in a crucial part of the ACPI table. Still, I'm gonna fix them. There is a good Howto on the Gentoo wiki which I will be using.
The last two errors are caused by the following code:
OperationRegion (CBR0, PCI_Config, 0x00, 0xE2)
Field (CBR0, DWordAcc, NoLock, Preserve)
{
[ Snip some code ]
Offset (0xE0),
C0E0, 8,
C0E1, 8
}
Since the last offset is 0xE0 and reads are word-aligned ('DWordAcc'), this reads up to (not including) 0xE0 + 4 = 0xE4. This means that the specified region size (0xE2) is exceeded. This can be fixed by increasing the region size to 0xE4. I'm not sure this actually fixes anything (or what the "CBC2" devices is, which this code concerns), but it does make the code compile.
The first error was caused by the following code:
Name (_PSS, Package (0x02)
{
Package (0x06)
{
[ Snip]
},
Package (0x06)
{
[ Snip ]
},
Zero,
Zero,
[ Snip nearly 200 zeroes ]
Zero,
Zero
})
Basically, what this says is _PSS is a package containing just 2 (0x02) items. Namely, another package with 6 (0x06) items, a second package containing again 6 items and a couple of hundred zeroes. No, that does not add up to a total of 2 items, but apparently the Microsoft compiler does not seem to care. Then again, the Linux kernel seems to care (see below).
The fix here seems to be just removing the excess zeroes. Also, this code concerns the CPU ACPI object. I particular, I think the _PSS fields define power states (which are 2 for my processor). I'm not sure of this yet, but I'll check it. For now, let's see what this does.
A simple reboot doesn't seem to change anything. No new devices, still only two power states. After some more debugging, looking up values in the acpi and powernow source code and in some AMD documentation it appeared that the last fix did actually change something. The powernow-k8 kernel driver takes care of scaling the CPU frequency up and down on load and while idling. Normally, this driver should get the data about which power states are available from ACPI. Turning powernow debugging on showed this did not happen. Instead, it used some legacy BIOS table to find the data. After fixing my ACPI table, the information about the power states (in the _PSS object) was fixed and it properly uses ACPI data now. The fact that the ACPI data is fully identical to the BIOS data doesn't really make the fix less cool.
The fun part is that I can now toy around with these settings. Some research shows that the frequency selection for powernow is rather awkward and follows a number of strict rules. Unfortunately the combination of those rules and the relatively low clock speed of my Turion (it's a mobile processor after all) make sure I have only two power states: Full (1600Mhz) and half (800Mhz). Tinkering with these (such as adding states in between) seems to involve modifying both the ACPI table and the driver to violate a few of the guidelines specified by AMD, so I will leave that for now.
Besides that, lspci now shows a number of AMD K8 devices (Hypertransport, DRAM controller, etc). Seems the ACPI fix did that. Dunno what they are for, but cool!
What I can do, however, is undervolt the CPU. This simply lowers the voltage of the CPU, so it will consume less power and produce less heat. At the first glance this seems to be rather effective. Though the effect on power usage is nearly zero when the CPU is in slow mode and idle, the savings are significant when the CPU is under load. Also, the idle temperature seems to drop by a few degrees. Pretty nifty. I have so for done a below.
Update: I've written an extensive post detailing how to undervolt this notebook
I will be fiddling around with the notebook some more soon. I'll hopefully be able to tell how to get bluetooth and wlan and other stuff working soon. Also, I've been dismantling my notebook today, to find out how it looks inside and if there is any room for RAM upgrades in the future. I took pictures while opening it up (since I could not find any guide on how to open it), so expect a detailed report soon.
I've found some more info on the net about using linux on the S270, from other people owning the notebook.
Hi, Could you please provide some more info on what you used to undervolt the CPU. I.e. what kernel version are you using, did you patch powernow-k8.c, did you use an external program (cpupw) or did you achieve undervolting in another manner?
Regards, youri
Hey,
I've added a new post describing the undervolting in detail here.
Could you please say if ACPI sleep works? How long is real-use on-battery time?
Yes, ACPI sleep worked pretty much out of the box. When using ati's fglrx drivers, I need to do a suspend-to-ram before I can do suspend-to-disk, but that's only once after each cold boot.
I've also been having some problems with kernel 2.6.16. With older kernels, the
noapictimer
option was needed to fix the system clock, but the bug causing this was fixed in 2.6.16 sonoapictimer
isn't needed anymore (even crashes on boot). Yet, without noapictimer, ACPI suspend seems to break.Summarizing, it works ok, but there are still some issues (though only minor).
Battery time is usually 3.5 hours (just over 4 hours when it was still new) when running at 800Mhz under light load (which is normal usage for me). I haven't measured battery life under full load, since I barely ever need that.
A very big thank you for your solution how to fix the DSTD. With the fixed DSDT Powernow is now working on my S270 (I have a Sempron, not a Turion). In the end I needed 10 months from buying the laptop to make it silent. No more annoying fan which goes on-off-on-off anylonger! :-D
it appears that Microsoft is not responsible for the "bunch of zeros" issue in the _PSS package. The reason why they appear is because BIOS produces the _PSS part of DSDT only at the boot time, depending on the CPU installed. So, BIOS manufacturers had to reserve some space just in case if a specific CPU will have too many different P-states. In my case it reserves 10 P-states, and since my CPU has just 2 P-states (as in your case), the rest of the reserved but unclaimed _PSS space is filled with zeros. You can extract the "virgin" DSDT (not yet modified by the BIOS duting POST) from your BIOS EEPROM with "flashrom" from LinuxBIOS, or from a BIOS update file, and you will see the 10 (or so) blank P-states I am talking about.
Well, it should really be trivial for the bios to limit the zeroes at runtime, or put up something dummy in that space (not only the data, but also a declaration).
IMHO Microsoft is still wrong here, since they accept the incorrect ACPI table without errors (since I would hardly expect BIOS manufacturers to deliver BIOSes that do not work with windows...)
Still, I'm no ACPI expert, so my opinion might be wrong...
may be it is not that easy to just shrink the DSDT table at the boot
Comments are closed for this story.