Quiet Computing

Laptop stuff

  • Getting a Toshiba 4600 Pro to run SuSE Linux 9.2

Misc stuff

First,I have a confession to make - I'm more of a BSD UNIX man these days and not so much a Linux man, although my first proper exposure to UNIX was Slackware Linux and I've been using SuSE on and of since version 4.something.

That out of the way, I do appreciate just how far Linux distributions have come in the past years and unless there's a compelling reason why one really, really needs to run a flavour of Windows, Linux can make a perfectly viable desktop alternative. Especially for a geek, as I think it'll probably take another couple of years until it becomes proper granny-proof.

Well, back to the topic at hand - getting SuSE 9.2 to play nicely with my Toshiba Satellite Pro 4600. I've had this for quite a while and I like it as it does everything I need it to, plus all the hardware one could want is already integrated into the system. No messing about with separate wireless and wired network cards and other annoyances like this. Well, almost.

See, I had this laptop for some time when I decided to put Linux on it as well as the pre-installed Windows 2000. I had just bought SuSE 9.2 at this point and decided that I rather liked it from a user perspective so that was the obvious choice. Booting the DVD was no problem and after the customary wait the installer refused to connect to the Internet and there was no joy in attempting to download the updates.

Unhappyness strikes

Only that at first bootup, the wired network card didn't want to play - instead, it refused to configure. Resetting it to a fixed IP didn't make any difference at all so it was clearly time to use the good friend of all people lost, Google.

That threw up a few answers but not the ones that I was looking for. In fact, it appeared that the world was full of people who had Toshiba Satellite Pro 4600s that didn't want to work with SuSE Linux, or at least the network interfaces didn't want to. In fact, the network interfaces appeared to be rather dead. Idly leafing through the pages of the administrators guide and some educated guesswork suggested that it may - just may - be the ACPI implementation that was to blame. I thought this would be worth a try so I decided to start from zero again and play with the configuration for as long as it took to get it working.

Redoing the setup

Before I reinstalled SuSE Linux I got the latest BIOS from the Toshiba website - not strictly necessary, but hey, it can't do any more damage, either. A quick test suggested that the new BIOS on its own wasn't enough to solve the problems so I went and started reinstalling Linux.

Only this time, I chose the installer with the ACPI functionality turned off instead of the default installation, which leaves ACPI on. Again, after the package selection and the customary wait for an hour for the installation to finish, the download of the additional updates suceeded without nay further problems.

So far, so good. I now had a working laptop - confirmed by rebooting it and still being able to access the network. The only thing that bugged me now was that the powermanagement was exclusively using APM as all the ACPI functionality had been turned off. This was clearly not such a brilliant idea as it also turned off useful functionality like SpeedStep and all the Toshiba ACPI-specific functionality like setting screen brightness. Clearly, time for some more experimentation.

Getting ACPI to work

As mentioned before, based on the symptoms of the non-working hardware my suspicion was going in the direction of the PCI ACPI routing. So as a next step I changed the kernel parameters for the bootloader from acpi=no to pci=noacpi. This has the effect of turning off ACPI for the PCI configuration and thus the interrupt configuration, but leaves the other parts of ACPI functional.

This configuration change did the trick. The system now booted as expected and the ACPI functionality is now available and working. The effect on battery life compared to APM is actually pretty noticeable, the battery meter suggests another 20 minutes runtime at least.