Holy Crap! I think it works!

OK, first off: Pardon me for the language, and pardon me for making yet another boring blog post about the PR200 and its acpi/battery issues. But I might have discovered something interesting here…

Last week I installed CentOS 5.2 on my laptop.
Why? I really can’t tell. For some reason I wanted to try something different but stable. And since I already had a short fling with CentOS a while back, but didn’t feel like I had given it a decent chance, I just chose to give it another go.

Anyway, I got it installed pretty smoothly, with the fully bloated GNOME desktop and all the other bells and whistles (except for compiz). And then I noticed that little icon in the System menu. It said “Suspend” next to it. Not expecting a great deal from it, I clicked it.

AND IT WORKED! Seriously. The laptop went to sleep. The power button flashed (which it is supposed to while suspended). And when I pressed the button, the laptop came back to life completely hassle-free.

Being a very skeptical, suspicious guy, I though it must have been a fluke. No other distro I had tried before did that out-of-the-box. In fact the only distro that managed to suspend the laptop was Ubuntu 7.10, but only after applying the System76 driver. And even then it didn’t always wake up like it should have, or it wouldn’t shut down properly afterwards, or the wireless would refuse to wake back up and reconnect,…

This time though, it woke up, I could reconnect to my wireless AP with one mouse-click, and the laptop shut down properly when asked to. Amazing!

Clearly a lot more testing is needed, before I go out there (well, here actually) and announce to the world that it works, like … properly. I already made the mistake of claiming that some of the issues were fixed, and five kernel builds later it was all messed up again. I’m not going to make an ass out of myself again (at least not consciously).

So, give me some time to do some testing (or try it yourself if you want to) and I’ll keep you updated.

And so I jumped the gun.

Yet again.

Altough the battery issue on the MSI PR200 was fixed for a short time. It didn’t really last long.
As of kernel 2.6.27-7, it’s all fucked up again. The computer doesn’t go into poll mode anymore, but stays in interrupt mode instead. Which is exactly what causes the battery state to be read wrong, and sometimes the battery isn’t even detected.

In my five years of using Linux, I can honestly say I’ve never encountered any hardware issue whatsoever. Everything I tried out, always worked well on all of my (reasonably old) hardware. Sometimes it needed a bit of tweaking and fiddling here and there, but in the end it worked. So I never really understood how frustrating it must feel to have something so essential to not work properly.

Until now …

The thing is, I’m really starting to rely on that laptop to be my main, stable and portable machine. The old laptop, and my desktop are machines to play and have fun with. And so I don’t mind if every now and then, something goes tits up on one of them. But the PR200 should always be there, ready and fully functional for me to work on.

So what now?

Well, yesterday I’ve installed Debian Lenny on it. Which is soon to become the next Debian Stable. And it’s currently running on a custom compiled 2.6.27-6 kernel (in poll mode).

It’s something that “just works”. And that’s exactly what I need right now.

In the mean time, I guess I’ll go back to regularly checking the relevant forum threads and bug report pages, hoping for a permanent fix.

Less Linux Laptop Woes.

If the WordPress stats of this blog are even a tiny bit correct, a considerable portion of my few visitors stumble upon this site after googling (or something similar) for ‘MSI PR200′ and ‘Linux’.

Now I don’t really expect all of these visitors to find what they are looking for here, but for some strange reason I do feel some sort of an obligation to at least try and post some kind of update on the issues I have been dealing with.

So, let’s recap first. What were those issues again?
Well, there was a small quirk with alsa not muting the speakers when on headphones. The power management was all screwed up, causing the battery state to be wrong about 90 percent of the time. And finally, both suspend (S3) and hibernate (S4) did not work.

The alsa issue was easily fixed by adding a certain line to the /etc/modprobe file. At least that’s what I think was needed, unless I’ve misinterpreted what’s in the System76 driver.
On kernels up to 2.6.22, the battery issue could be fixed by using the ec_intr=0 boot option. As of 2.6.23 or 2.6.24 however, that option was no longer available, so we were back to were we started. (Which was also the reason why I stuck with Ubuntu 7.10 for a while.)
That same kernel bump also caused S3 and S4 suspend to break, which I had gotten to work thanks to the System76 driver on Ubuntu 7.10 (and some mysterious custom DSDT.aml file).

No more daru2 ?

It seems that System76 has stopped selling the Darter Ultra 2, a.k.a daru2, a.k.a the same notebook as my MSI PR200.

Now, I don’t know for how long they have been selling this model, or how long they usually have a particlar model on sale, but I can’t help but wonder if this could have something to do with the difficulties of getting it to play nice with kernels 2.6.24 and above.

According to Thomas Aaron on the System76 forums, they are planning a replacement (the daru3 I suppose). I have to admit that I’m pretty curious to what it’s going to be. Not that I’m planning on replacing my laptop. Heck, I just got it.

Nevertheless, I’m sure they’ll continue to offer the best possible support to their existing daru2 customers. And they’re probably still working on a better fix for the powermanagement and battery issues. Hopefully they’ll find it soon. So that I can shamelessly leech of it.

This tiling stuff isn’t all that bad.

Brasi, my old Dell laptop, is starting to show signs of old age.

Obviously, this was far from a high-end machine when I bought it (second handed) back in 2006, and it was never expected to run extremely smooth or fast. But lately, one problem has been resurfacing over and over again, which seriously hinders it from operating normally:

Sometimes the mouse cursor just spears of to any given corner of the screen, and remains ’stuck’ there, leaving me with a very dysfunctional graphical environment.
I’m pretty sure this is a hardware problem, caused by plain old age, and not a software one, since I’ve noticed this little quirk happened on several installs, of several different distributions.

Up to now, the solution has been pretty simple; Either I wait for a while until the laptop’s little tantrum is over. Or, using my most sophisticated mechanical skills, I give it a good knock. However, it has aggravated up to a point that waiting just takes too long and hitting it just causes the cursor to “flee” to another corner of the screen, still remaining ’stuck’.

So now the situation calls for a more thorough solution, which leaves me not depending that much on the ability of using the mouse. In other words, I need to specify enough keybinds to allow me “do” everything I used to “do” with the mouse. Luckily, this can easily be set up in ~/.config/openbox/rc.xml, the main configuration file of my favorite window manager, Openbox.

Nonetheless, this is not what I’ve done (yet).

Dualbooting, a waste of disc space.

Well, in my case, it was.

I had Ubuntu Hardy and Arch Linux on my laptop for a few weeks, but due to the powermanagement problems on 2.6.24 kernels (and above), I hardly ever booted into the Arch install. I know Ubuntu 8.04 also has a 2.6.24 kernel, but I was using a workaround on it that partially solved the battery issue with my laptop (thanks to pavel_987 and badbull).

Still, it lacked the support for suspend and hibernation, and the workaround was causing some strange battery errors, when unplugging from AC power.

The brave/smart/best/ideal thing to do was to actively try and work on a solution myself. But alas, I took the lazy route and did a clean install of Ubuntu 7.10, in which hibernation at least works and the battery state is read correctly.

Meanwhile, the good people of System76 are still working on a solution for both the battery and the suspend/hibernate issues. It’s proven to be a tough nut to crack. But since I’m not really one of their customers (they don’t ship outside the U.S. and Canada), I’m not really in a position to complain about it.

Again, I promise to keep following up on this issues and I’ll do my best to post updates on my blog as soon as possible.

Hostnames … revisited.

Hostnames, and ‘names’ in general are important. Clear and simple.
They make it easier for us to identify a machine or a node, especially on a network or a group of networks. If we would have to remember and recognize every machine or node by its IP address, or even worse its MAC address, it would all get very complicated.
Hostnames, and ‘names’ in general can also be fun. It’s fun to name things for a specific reason. Or at least, I think it is.

Anyway, to the point:
With all the new machines, networks, etcetera I now have around here, I needed to rethink some of the names I had given to my “things”, and also come up with some new ones.

Before, I’ve already explained my geeky, exaggerated method of naming my “stuff”. To summarize, I name them after characters from “The Godfather”.

And if you thought I was exaggerating back then, wait ’till you see the new list. This time I really went bonkers …

The System76 driver … again.

Again I know, but it’s just one of the most pressing linux-related issues I’m dealing with at the moment. And it probably won’t be the last blog post about it.

Anyway..

I did some further testing with the driver on Ubuntu Gutsy, followed up on the important topics on the Ubuntu Forums, and I learned a few more things:

As Jose commented correctly, suspend works, but only to a certain degree. I had set up the laptop to suspend automatically when the laptop lid was closed, and it did, but sometimes it wouldn’t wake up afterwards. Other times it would wake up, but when I wanted to shutdown later on, it hung. Forcing me to shut it down “the windows way” (keeping the power button pressed for ten seconds until it died).

The sound is indeed a bit flakey, but once you know how to handle it, the workaround is simple. When using a headphone jack, you basically have to make sure the front speakers are muted and the headphone switch is ticked on in the Gnome Volume Controls. This isn’t really a big problem as long as you use Gnome to control the volume, or something similar. I don’t know how I’m going to handle it when I set up Openbox, but if necessary I’ll just load up a small part of Gnome to get it working.

So apart from that, on Gutsy, the rest worked pretty well.

Alas, that is not all…