Red Hat Bugzilla – Bug 132708
kernel won't boot up on Asus A7V133 with nothing connected to the VIA primary IDE channel
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
The Asus A7V133 motherboard has a built-in VIA IDE controller, that
gets IDE devices hd[a-d], and a built-in Promise Ultra100 TX2 IDE
controller, that gets IDE devices hd[e-h].
I used to have a hard disk in hda and one in hde, plus a CD recorder
in hdc, and everything was fine.
I had reasons to move some disks around, so I ended up changing the
disk arrangement such that hde moved to hdg, hda moved to hde, and hdc
(the CD drive) remained in place. Nothing in hda. No cable
connected. Nothing reported by the BIOS.
However, Linux wouldn't boot. grub would load the kernel, and the
kernel would print the audit message and just sit there, waiting for
someone to reach for the reset button.
So I rebooted without quiet, and I could see that, right after probing
the VIA controller, it started probing for hda, and it would get
time-outs, and keep trying.
There was nothing in hda or hdb. I don't see why it kept trying to
find something there.
I ended up moving the CD drive from hdc to hda, and then the machine
would boot up fine again.
Let me know if you need additional info to track the problem down. I
can't get much more than the time-out messages printed by the kernel,
but I didn't take note of them, so I'll have to change cabling again
to get them. Let me know if it would help, otherwise I won't bother.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set up an Asus A7V133 with 2 HDs and 1 CD drive.
2.Connect the HDs to as masters in the Promise channels
3.Connect the CD drive as master in the secondary VIA channel
4.Try to boot
5.Move the CD to the primary VIA channel
6.Try to boot
Actual Results: 4 hangs; 6 works
Expected Results: I can't think of a reason for 4 to not be expected
It should keep trying (although not forever) if it is sure a device is
present, that may be because you have a cable but no drives, or
because the bios entries said there was a device on hda that didnt
exist. Otherwise I too would have expected it to skip the
Does/did hda=ignore help ?
No cable. IIRC it printed hda=pio, as opposed to dma, which generally
implies there's no disk there. But there used to be. The BIOS was in
Auto-detect mode for primary/master, and it didn't detect anything at
boot time, nor did it print disk info in the BIOS disk configuration
screen, which implies nothing was set up.
It might be that something was left over from the previous
configuration, though. Hard to tell. I'll poke around a little bit
and see if I can duplicate the problem again, now that there was a CD
drive on that location. Thanks for the insights.
Moved the CD back to hdc, entered the BIOS to make sure the settings
were right, and voila, it stops the boot again.
Messages are like:
hda: IRQ probe failed (0xfcfa)
hda: no response (status = 0x0a) , resetting drive
hda: no response (status = 0xa1)
hda: no response (status = 0xa1), resetting drive
the same messages are printed for hdb as well, regardless of whether I
have hdb=ignore as well or not.
It actually completes the boot after several of these, but it takes a
hda=ignore and hdb=ignore, either or both, doesn't make any difference.
Explicitly disabling the slots for hda and hdb in the BIOS settings
doens't make any difference either.
just use these kernel parameters:
I got 10seconds delay and all boot faster.
Before, I got 30 seconds for hda and 30 seconds for hdb
It really speeds the boot process
BIOS problem I believe not kernel. We only probe hda/hdb because the BIOS claims
the slot may have a drive on it.
Having looked at some similar problems I'm going to close this one as the same.
There are two variants of the problem I've seen
1. BIOS doesn't route IRQ for IDE if there is no drive on primary but doesn't
mark the drive slots as empty
2. Similar but the IRQ is routed.
Closing as "WONTFIX" but "NOTOURS" would be closer if it existed 8)
You may find acpi=off helps but most likely not
I think comment #4 solves this problem.
Maybe this bug should be marked as: WFM/WORKAROUND