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
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 -
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
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.