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-126.96.36.199.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
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
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
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
Does reverting the patch mentioned here help?
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
It is quite plausible that reverting the patch in question could help
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?
This one, right?
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)
I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug, however this version of Fedora is no longer
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!