Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232490 - kernel update 2.6.20-1.2925.fc6 refuses to boot without 'acpi=off irqpoll'
Summary: kernel update 2.6.20-1.2925.fc6 refuses to boot without 'acpi=off irqpoll'
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
Reported: 2007-03-15 19:02 UTC by Michal Jaegermann
Modified: 2008-01-08 02:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-01-08 02:21:28 UTC

Attachments (Terms of Use)
dmesg output for 2.6.19-1.2911.6.5.fc6 (deleted)
2007-03-15 19:02 UTC, Michal Jaegermann
no flags Details
initrd for 2.6.20-1.2925.fc6 (deleted)
2007-03-23 23:19 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2007-03-15 19:02:03 UTC
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.

Comment 1 Michal Jaegermann 2007-03-15 19:02:03 UTC
Created attachment 150155 [details]
dmesg output for 2.6.19-1.2911.6.5.fc6

Comment 2 Chuck Ebbert 2007-03-20 15:16:12 UTC
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.

Comment 3 Michal Jaegermann 2007-03-20 21:47:53 UTC
> mkinitrd --without=ahci.ko ....

There are some small gotchas with this suggestion. The first is
that mkinitrd, at least mkinitrd-, 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'.

Comment 4 Chuck Ebbert 2007-03-23 21:53:35 UTC
Can you upload the original initrd for kernel 2.6.20-1.2925.fc6?

Comment 5 Michal Jaegermann 2007-03-23 23:19:05 UTC
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
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.

Comment 6 Chuck Ebbert 2007-03-27 20:29:26 UTC
Can you try booting with kernel option "pci=nomsi"? Apparently the SB600 driver
may not be able to use MSI properly.

Comment 7 Michal Jaegermann 2007-03-27 21:20:04 UTC
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

Comment 8 Len Brown 2007-04-25 05:37:21 UTC
Does reverting the patch mentioned here help?

Comment 9 Michal Jaegermann 2007-04-25 15:22:21 UTC
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
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.

Comment 10 Chuck Ebbert 2007-04-25 19:17:41 UTC
(In reply to comment #8)
> Does reverting the patch mentioned here help?

This one, right?;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.

Comment 11 Jon Stanley 2008-01-08 01:53:47 UTC
(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!

Note You need to log in before you can comment on or make changes to this bug.