Description of problem: On ASUSTeK board M2R32-MVP 2.6.19-1.2911.6.5.fc6 was booting without any extra parameters (and hard drives were showing as /dev/hda and /dev/hdc). After an update to 2.6.20-1.2925.fc6 I had to use 'acpi=off irqpoll' before the machine in question booted at all. Drives are now taken over by libata and are /dev/sda and /dev/sdb. It appears that, fortunately, with the board in question parameters used do not have crippling effects. I could not try too many options as I was doing that over a phone with a person on the other end who is quite far from a Linux hacker; but I did try 'libata.noacpi=1', although only by itself, and that did not help. I guess that this is really another manifestation of bug 229621 which was filed previously for rawhide. Still dmesg output from a boot with 2.6.20-1.2925.fc6 is attached here. Other samples and information, including dmidecode output, can be found in attachments to bug 229621.
Created attachment 150155 [details] dmesg output for 2.6.19-1.2911.6.5.fc6
You should be able to work around this problem with: mkinitrd --without=ahci.ko <initrd name> <kernel version> Make a new initrd -- don't overwrite the existing one. Then edit /etc/grub.conf and point it at the new initrd.
> mkinitrd --without=ahci.ko .... There are some small gotchas with this suggestion. The first is that mkinitrd, at least mkinitrd-5.1.19.0.3-1, does not have such option at all. Also looking at /sbin/mkinitrd script I do not a way to skip a specific module like ahci.ko. Still in order to test that I unpacked initrd in question and edited 'init' script on it no to load ahci.ko; or that and additionally no libata.ko as well. In both cases a root file system simply cannot be found so there is no way to boot. Actually 'init' scripts on initrd look the same for 2.6.19-1.2911.6.5.fc6 and 2.6.20-1.2925.fc6 only disks are handled in a different way. BTW - I tried booting on the same board and 2.6.20-1.2933.fc from "updates-testing" and I am still going nowhere with it if I will not pass 'acpi=off irqpoll'.
Can you upload the original initrd for kernel 2.6.20-1.2925.fc6?
Created attachment 150806 [details] initrd for 2.6.20-1.2925.fc6 Note that although I have an access to the machine in question it is right now remote and "in production" and I am not free to experiment with it as I please. There are other mine reports about that hardware which, as I see that now, seem to be closely related. C.f. bug 229621, and comments in it from #5 down, and also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221691#c12 and following. In the last case it is quite likely that this is buggy hardware/firmware of a DVD writer. Still when I am running 2.6.19-1.2911.6.5.fc6 then polling by hald is not causing a constant stream of errror messages. If I will switch to 2.6.20-1.2925.fc6 then I have a choice - stop hald or flood logs with tons of garbage. There was no changes with a recent kernel from updates-testing. I was able to try that on a different setup with the same mobo.
Can you try booting with kernel option "pci=nomsi"? Apparently the SB600 driver may not be able to use MSI properly.
I did not write it directly here but see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621#c7 which in that comment talks about 'pci=nomsi' explicitly. It did not change a thing. This is basically the same problem and various information attached there could be useful. I wouldn't mind to run more experiments but I am aftraid that at this moment I do not have an access to that hardware. Quite likely later.
Does reverting the patch mentioned here help? http://bugzilla.kernel.org/show_bug.cgi?id=7562
Unfortunately it could be a while before I will be able to answer the question from comment #8. It is quite far from me having this machine on my desk. I will see what I can do. OTOH from what I can gather from a discussion in a quoted reference kernels considered there do not boot on the board in question at all. At least I could not find any kernel parameters which would allow me to accomplish that feat. Please see more precise description at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235787 It is quite plausible that reverting the patch in question could help with that. Mentioned in bug 235787 kernel-2.6.20-1.3053.fc7, which I was able to boot there using 'acpi=off', is one of Fedora rawhide kernels and corresponds to 2.6.21-rc6-git1. So far I did not have a chance to repeat that experiment with one of newer rawhide kernels.
(In reply to comment #8) > Does reverting the patch mentioned here help? > > http://bugzilla.kernel.org/show_bug.cgi?id=7562 > This one, right? http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commitdiff_plain;h=7639e962234c76031d1ddf436def7fd9602be560 It's now been reverted upstream and I'll send that revert for -stable. That means it will be in the next FC6 kernel update.
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!