..but it works with Windows...

When dealing with Linux kernel bugs I frequently hear the phrase "..but it works with Windows..". This can be rather galling, why can Windows work correctly when Linux seems to fail? Well, there are several reasons.

First of all, when Windows is shipped with a PC it generally has a whole load of extra drivers bundled with it to handle weird non-standard stuff, such as hotkey handling, wireless/bluetooth kill switches and so on. Some OEMs ship new PCs with the Windows install disc and a CD/DVD with all the extra drivers. Other OEMs ship PCs with a magical restore partition that installs Windows and it's extra drivers in one go to save the hassle of messing around with all the extra drivers. Sometimes these drivers just work around non-standard PC weirdness - this can be where Windows works and Linux does not.

Secondly, Linux relies on the BIOS ACPI tables being correct. For example, yesterday I looking into a bug where a N280 Atom based machine could only run at 1.333GHz when the processor is in able to run at 1.666GHz. For some reason Windows worked correctly and Linux did not. Some digging around in the BIOS and the ACPI driver showed me that the Linux ACPI driver was correctly reading the BIOS settings and it was a buggy BIOS. This seems to indicate that somehow Windows was ignoring this incorrect data. What do you do in these cases? Apart from booting with acpi=off (which is a horrible workaround) I suppose one just needs to ask for a BIOS fix to such issues.

There are other reasons too, but the first two are generally the main causes.

Over time, the kernel just gets more and more weird workaround quirks added to fix such issues - but the crux of the matter is this - Windows has the same kind of kludges but generally they are ironed out before a PC hits the high street - and a lot of these Windows kludges don't get fed back into the mainline Windows installation because it's closed source and it's easy for PC manufacturers to just add on their own hacks to the OS.

Meanwhile, I will continue to try and sort out BIOS problems and to make sure Linux works out of the box...

Netbook computing a success!

OK, I've nearly completed 2 weeks just using a Netbook and I think it's a complete success. The experiment using a HP Mini 1000 running an Alpha version of Ubuntu Karmic proved I can get by without the need of a bulky and power hungry Laptop for all my day-to-day work.

The netbook worked out especially useful while I attended Linux Plumbers in Portland. It's light, compact and I got a reasonable amount of up-time as long as I judiciously used suspend/resume.

Will I be dumping my Lenovo 3000 N200 laptop? Possibly not, but I'm convinced netbooks are the way forward for easy portable mobile computing.

Semi-Daily Summary of Kernel Development News from LKML

Jon Masters is running kernelpodcast.org which provides a semi-daily summary of the Linux Kernel Mailing List (LKML) Email traffic. The site contains podcasts and audio transcripts and is a great way of keeping up to date with kernel development without having to read 10 thousand of Emails a week. Thanks Jon - great work!

Using the noop I/O scheduler

Over the past few days I've been tweaking the configuration on my HP Mini 1000 to see how to squeeze a little more performance out of this device. Today I enabled the NOOP I/O scheduler on the SSD as this improves performance a little.

Since the SSD is just a flash memory based device, it has minimal seek time and zero rotational delay, so it's sensible to disable the more complex default cfq I/O scheduler and just use the simpler NOOP scheduler. The NOOP scheduler just puts all I/O requests into an unordered First-In First Out (FIFO) queue, and can also do request merging. The rationale behind this is that I/O performance optimisation is performed by the block device such as the logic in the SSD controller.

Traditional hard disks have the overhead of head movement seek times and also rotational delay and it makes sense for these devices to try and group I/O requests together if they are physically close on the disk. However, with SSDs this does not make sense as these delays don't apply - the NOOP I/O scheduler is a better choice as it removes the grouping of I/O requests and hopefully reduces the variability in timing of I/O request completion.

To enable the NOOP I/O scheduler on SDD device /dev/sda, I used (as root):

echo noop > /sys/block/sda/queue/scheduler

..and of course this should be placed in the appropriate boot scripts.