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!