I have had a lot of angst about what to replace my iBook with, and I settled on the Lenovo U150. I have some observations which may be useful if you are considering whether to purchase it, or trying to get Linux to run on it.
I installed Debian on it. I used a custom-build Linux 2.6.32.7 kernel. It was a fairly painless netboot installation, with the exception of the BMC Tigon 3 Ethernet driver (CONFIG_TIGON3). It required a separate component (CONFIG_BROADCOM_PHY) for PHYLIB. And it never would reinitialize successfully after the interface was ifconfiged down (which Debian insists on doing for netboot installs). For that issue, I obtained a preliminary patch from the maintainer.
Seems to work fine for me and should be in the mainstream kernel soonish.
The wireless card (CONFIG_IWLAGN and CONFIG_IWL5000) needed me to download firmware for it. No big deal.
The laptop is fairly quiet, but much louder than the iBook was (its fan is always on...it is very small but very fast). I'm afraid I'm going to be taking this thing apart constantly to clean out the cat hair. *sigh* It draws a ridiculously large sum of electricity while idle, and dissipates it as heat. It is a major disappointment in that regard. Linux seems to take advantage of all of the power saving features of the Intel Core 2 Duo (SpeedStep, MWAIT C3 state, etc). But it doesn't do any good. The damn chip won't clock any slower than 800MHz, period! What a joke, since even my hot desktop 1.83GHz Athlon can be clocked at 600MHz for cool operation. I kind of hoped that Core 2 Duo was the shit, since it managed to persuade Apple. But alas, Core 2 Duo is shit.
On the other hand this laptop is very fast. I haven't had anything take noticable wall clock time. Even Firefox is plenty responsive. Even resuming from sleep only takes about 3 seconds, which is as good as the iBook. And so far resume has been flawless, and it draws very little battery power. Setting up sleep/resume on lid close/open was as easy as installing acpid and putting a line in /etc/acpi/lid.sh:
echo mem > /sys/power/state
Can't be too clever there because the lid sensor just reports transitions, not actually the current state of the lid...you just have to trust that the lid open event at resume will be gobbled up (lost) as part of resuming so it won't double-sleep.
The touchpad was almost unusable in X. The Synaptics input driver completely solved my issues. I just installed xserver-xorg-input-synaptics. Here is the section in xorg.conf for it that I am using at the moment (though I feel a little dirty for referencing /dev/input/event6 directly.../dev/input/mice does not seem to work (reliably?):
Section "InputDevice" Identifier "Mouse0" Option "Device" "/dev/input/event6" Driver "synaptics" Option "Protocol" "event" Option "LeftEdge" "1200" Option "RightEdge" "5000" Option "TopEdge" "1200" Option "BottomEdge" "4800" Option "FingerLow" "25" Option "FingerHigh" "50" Option "MaxTapTime" "0" Option "MaxTapMove" "0" Option "VertEdgeScroll" "true" Option "CornerCoasting" "true" Option "CoastingSpeed" "1.0" Option "VertScrollDelta" "100" Option "MinSpeed" "0.4" Option "MaxSpeed" "2.0" Option "AccelFactor" "0.0015" Option "SHMConfig" "on" EndSection
Battery life isn't too stellar (only about 3 hours in practice), but that's apparently to be expected.
The speakers are plenty loud, but the microphone input doesn't work yet. It needs a special model= option for the Intel HDA audio module (snd_hda_intel). Okay, I figured all that out. And here is a patch to linux-2.6.32.7/sound/pci/hda/patch_conexant.c. It even automatically senses internal vs external microphone/speaker. I've submitted it to the upstream maintainer so hopefully it, too, will be widely available soon.
It is a pretty sexy little laptop. It is really only slightly smaller than the iBook, but it seems much smaller, and not in a super obnoxious way. Though it is as small as I would want to go, probably. And though I like how it looks, I'm not sure that the widescreen format is actually superior. For one, it doesn't quite fit my favorite font right in an 80x25 rxvt.
It is reassuring to see that modern mainstream free Linux now has so many of the little utility daemons and infrastructures that made environments like Darwin and Maemo so convenient. For example, I like acpid and udevd, and I love all of the /sys and /proc interfaces to things such as processor power state. I don't know how everyone else does things but my way of administrating OS X, which I've come to like, is quite fruitful on Linux.
The thing which surprised me most when I switched back to the iBook for a while is just how many crapulent things I've gotten used to that I really don't like. For example, I gave up years ago at getting the keyboard configuration the way I wanted it, and it has been a minor nuissance for that entire time. On the U150, so far, I have not had to compromise on anything UI wise.
I've been thinking about what made the iBook special that is lacking in the current laptop, and I have come up with a list:
In other news, I have been playing with Intel SpeedStep. On the Core 2 Duo it seems to be that the MSR has the following bits:
These values are set through MSR 0x199:
wrmsr -p0 0x199 0x100008608 wrmsr -p1 0x199 0x100008608
You can read the current status with:
rdmsr -p0 0x198
Note that you must use something like "cpufreq-set -f 800000" to turn off any dynamic CPU frequency governors or the kernel will override your settings.
I built up a little table by setting the MSR and then running a stupid little benchmark to verify it took effect. I also monitored (in a haphazard fashion, I suppose) the battery draw (current) meter on my laptop and recorded the minimum and maximum that I observed. ACPI provides a way for the BIOS to tell the kernel known-good values for the MSR, which i have labelled as "stock" in this table.
| MSR 0x199 | meaning | time (est speed) | current | stock? |
|---|---|---|---|---|
| 0x100008608 | 6x100MHz 0.83V | 3.558s (600MHz) | 1.05-1.09A | no |
| 0x10000860b | 6x100MHz 0.88V | 3.558s (600MHz) | 0.96-1.11A | no |
| 0x10000880d | 8x100MHz 0.91V | 2.677s (797MHz) | 0.95-1.12A | yes |
| 0x100008a0e | 10x100MHz 0.92V | 2.130s (1002MHz) | 1.05-1.18A | no |
| 0x10000060f | 6x200MHz 0.94V | 1.779s (1200MHz) | 0.95-1.20A | yes |
| 0x100004617 | 6.5x200MHz 1.07V | 1.642s (1300MHz) | 0.95-1.27A | yes |
As you can see the thing comes with 800MHz, 1200MHz, and 1300MHz by default. I thought it was stupid that it could do 600MHz but the BIOS didn't support it. But now I know it doesn't matter. See, if you let the idle system settle long enough (these tests were mostly not idle) then it will draw as little as 0.95A, regardless of the CPU frequency. In other words, when it is in the HALT state at 1300MHz it is almost as efficient as when it is in the HALT state at 600MHz. Which sounds kind of neat but really it obviates SpeedStep because the converse is true: when it is in a HALT state at 600MHz it is as inefficient as at 1300MHz! Even reducing the CPU voltage doesn't have a significant effect.
So SpeedStep is basically useless and retarded, and only controls the maximum amount of performance and power consumption you will experience. If you don't use 1.3 billion cycles of CPU power then it won't draw any extra current no matter what the clock rate.
Verdict: it's not worth hacking the 600MHz mode into the driver.
This is a real disappointment because I had an Athlon XP 2500 desktop processor that did much better. At 1.83GHz, it was hot and drew so much current that it melted its power supply capacitors on the motherboard. Once the capacitors failed to a certain point, it would crash all the time so I was able to reduce it to ~500MHz and achieve a substantial savings. The thing ran cool, the power supply was not stressed, etc. My only consolation is that the Core 2 Duo probably draws less at peak utilization than the Athlon drew ever, but that's just a generation difference. These days, we ought to be able to do better. We ought to be able to set the CPU into an idle mode where it draws almost no current. As near as I can tell the CPU is the major consumer in this laptop, as it draws around 800mA in its most idle state with just the CPU, RAM, and display operating.
As an inspiration of what is possible, there is the Nokia n800. It operates around 300MHz peak and scales down to about 150MHz when it is not in use. Its CPU remains active at all times, even when it is "off". Which is pretty awesome because you can SSH into it or run monitoring tasks or whatever, even if it appears off. It gets about 4 days of idle battery life, but if you ask the CPU to perform then it can chew through the whole battery in a couple hours. This is more like what I would expect to see out of a decent mobile processor. The idle power consumption should be approximately zero, giving you a full day or so of battery life in general. Then if you run video games or whatever then it should burn up the battery.