Ubuntu 8.04's Generic Kernel Hangs Machine

(Updated: To solve your problem, upgrade to Ubuntu 8.10. The newer kernel does not suffer from the problem mentioned below)

If you are using a Vostro 200, this post may apply to you, but bear with my few paragraphs of rant before I give you a fix to the problem. :)

Bloody linux has done it again, borking up my machine during an upgrade cycle. That’s always why I’m hesitant on upgrading unless there is no choice. I’ll leave the FOSS purists to argue about the concept of ‘free’ in whatever way they like, but I’ve always been mindful that there is a hidden cost involved in using Open Source software - you’re paying it with your time as a guinea pig for the developers to solve the problems you’ve encountered.

One way to mitigate that cost is by not using the most cutting edge versions of software - in that way, you’re relatively safe from any initial teething issues that still needs to be fixed. But the bad news is, stable/working probably equals to 5 years or more in the FOSS world, and computer hardware moves faster than that.

Given the fast turnover of computer peripherals, no sensible shop will stock 5 year old hardwares to sell it to you, and hence my problems started when I added a new ATI Radeon card to the system. The last known working kernel for the Vostro had been 2.6.22-14-generic, which I had found out a long time ago when I had ‘apt-getted’ a 2.6.22-16-generic kernel. The obvious quick-fix then was to be make GRUB boot my older kernel, to which I left it at that.

But given that I had installed a new card and needed to install ATI’s newest driver, the driver installer, in cahoots with dkms, decided that I wanted a 2.6.22-16-generic kernel module, which obviously screws up X, and hangs my machine whenever the xserver tries to start.

So I’m left with the situation that either the kernel will hang, or X will. Greeeeat.

Since I had been holding off upgrading from Gutsy to Hardy for a long while, I decided to take a gamble to see if the upgrade to a newer kernel would have solved the problem, since it’s probably 1 year past the last release cycle. But it turns out to be a real awful mistake - upgrading to 2.6.24-23-generic still screws up the SATA controller, ejecting me to busybox’s prompt after giving the following messages:

ata1.00: qc timeout (cmd 0x27)
ata1.00: failed to read native max address (err_mask=0x4)
ata1: failed to recover some devices, retrying in 5 secs

...

ata2.00: qc timeout (cmd 0x27)
ata2.00: failed to read native max address (err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs

...

I can imagine Mac users laughing with derision at me right now - ‘Get a Mac, it just works!’

After wasting two nights of precious time booting into my old kernel and trying to coax xserver and the fglrx driver to play nice, I decided to revisit the issue of fixing the kernel problem. After a bit of digging, I found the solution in launchpad’s bug report: ‘Ata Revalidation Failed’. To solve the problem, add the argument 'irqpoll all_generic_ide' into the kernel line in GRUB:

title        Ubuntu 8.04.2, kernel 2.6.24-23-generic
root        (hd0,0)
kernel     /boot/vmlinuz-2.6.24-23-generic root=UUID= ro irqpoll all_generic_ide
initrd        /boot/initrd.img-2.6.24-23-generic
quiet

I don’t know what exactly the kernel flag does, but I suppose the SATA controller wouldn’t jive with the kernel and needed a jolt of forcible of polling from the kernel for it to work.

#Linux