Red Hat Bugzilla – Bug 27648
[promise] Initial (installation) boot hangs after detecting hard drive on Ultra66 ATA
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Kernel doesn't boot with hard drive on the Ultra ATA/66 IDE (Promise)
Appears to be the initial situation described in bug 25834 which
mutated to some problem in LILO. The original problem wasn't addressed.
Steps to Reproduce:
1. Try to boot Fisher CD #1 on a Gateway Performance PC
Actual Results: Kernel boot hangs at hard disc detection.
Expected Results: Kernel should boot.
It seems that there is some problem with detecting the Ultra ATA/66 IDE
controller from Promise at boot time. I can manually transcribe some of
the output if necessary - the last few lines after listing the drives are:
hde: Quantum Fireball
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x14a0-0x14a7,0x1496 on irq 3
From bug 25834, it seems that moving drives to different controllers will
fix the problem (eg I found that moving the hard disc to the motherboard's
IDE controller allows the installation to boot, but breaks Windows 2000).
I upgraded the controller's BIOS support with no change in behaviour.
It seems very bad that some people using an Ultra controller will need to
mess around inside the computer to get things working!
Is there any more information I can provide?
I have one of these cards I use daily - something must be different about our
configurations. Perhaps it is the type of drive you have attached.
OK - according to Windows the drive attached to the Ultra 66 is a Quantum
FireballP KS SCSI Disk Device. The CD on the motherboard's IDE controller is a
Other relevant information I tried to get from Windows:
The Ultra card uses:
I/O: 14a0-14a7, 1494-1497, 1498-149f, 1490-1493, 1400-143f
The IDE ATA/ATAPI controller is Intel 82371AB/EB PCI Bus Master, using
The secondary IDE channel:
Device 0 uses PIO Mode and Device 1 is auto detected and uses DMA if available.
I/O: 0170-0177, 0376-0376
Are all your IDE devices on the Ultra66?
What is the kernel trying to do when it hangs? Is there anyway that I can
persuade it to skip that step with boot parameters?
Perhaps you could add a note that some configurations with Ultra66 cards have
problems? Then at least we'd be forewarned.
I'll try switching cables around and see if that solves the problem, as it did
We (Red Hat) should really try to resolve this before next release.
OK - my last comments/update appears to have failed, so in summary:
No progress - the only way I can boot to the installation is to have the CD-ROM
and hard drive on the motherboard's IDE controller. That stops Windows booting,
so that's a no-go unless someone tells me how to fix that.
Trying to boot with a disc compiled from kernel.org's source didn't work (hangs
in the same place) with any configuration with the hard drive on the Ultra-66
card (even with the motherboard's IDE controller disabled).
I can try booting different kernels from a floppy if you tell me what to change
to get more info on what is going wrong.
Please try with our latest Wolverine beta release.
I have a system very similar:
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio
PDC20262: IDE controller on PCI bus 00 dev 68
PCI: Found IRQ 9 for device 00:0d.0
PCI: The same IRQ used for device 00:04.2
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xa400-0xa407, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xa408-0xa40f, BIOS settings: hdg:pio, hdh:pio
hdc: CD-524EA, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
hde: Maxtor 91366U4, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xb800-0xb807,0xb402 on irq 9
This system installs from CDROM and boots from the Promise IDE bus (drive
/dev/hde) w/o any problems.
I'm ready to mark this 'WORKSFORME', but I want to see if wolverine works for
the bug reporter first.
Qa department making the call that this appears to be a kernel issue.
OK - I've just managed to finally download Wolverine and test it - same problem
I'll see if I can get any more information from some kernel source. If any one
has any suggestions I'd like to hear them!
I found some information on a linux-kernel mailing list archive (eg)
This describes exactly the same problem as I've experienced and gives a patch,
so my question is now is the patch in the wolverine kernel? I will try and
check myself, but it'll take some time.
The patch suggested in the above posting isn't in kernel version 2.4.2, so I'm
assuming that it isn't in wolverine either.
The change is:
> or by commenting out the lines
> if (IDE_CONTROL_REG)
> OUT_BYTE(drive->ctl | 2, IDE_CONTROL_REG);
> in ide-features.c/ide_config_drive_speed();
I have managed to make a boot disk that apparently works - it doesn't appear to
agree with the library versions of the installation on the hard drive though
and so the boot doesn't complete. However it does get passed the original hang
and does appear to mount the linux partition.
Is there any way to proceed with installing and checking wolverine now that I
have a partial solution to the original problem? Or will I have to wait for a
properly corrected version to be released?
"SCSI Disk Device" -> Is this the Promise fake-raid controller kind ?
> "SCSI Disk Device" -> Is this the Promise fake-raid controller kind ?
I don't know. All I know is that under Windows it reports itself under the SCSI
and Raid controllers:
Win2000 Promise Ultra66 (tm) IDE Controller (PD)
Looking at the Promise web site and the card itself, it looks like the
Ultra33/66/100 and has nothing that indicates RAID on the card.
Does this card have 2 IDE connectors on it (so you can hook up 4 drives) ?
It does have two ide connectors.
Further information - I have got linux installed and working on the machine,
although it took a rather complex route:
Install fisher in expert mode (to avoid rewriting MBR) using working IDE
controller on motherboard.
Make a new kernel (2.4.2) with the above patch made, make a boot disk.
Change the kernel's root directory using:
rdev /dev/fd0 /dev/hde6
Shutdown and move hard drive back to Ultra 66.
Boot using the boot disk.
Set up the /dev/hde6 boot sector using lilo (might have worked before the
reboot, but seemed safer this way).
It now boots happily with Windows 2000 off the Ultra 66 controller.
There were various complexities along the way, but nothing fatal and probably
due to me doing things too fast.
Can you give me the output of
(and also for all other drives connected to the promise controller, by
replacing hde by the appropriate name)?
The output of cat /proc/ide/hde/model is as follows:
QUANTUM FIREBALLP KX20.5
This is the only drive connected to the promise controller.
This device is added to the list of "weird" devices in the Promise driver;
Several other Quantum drives were already in it, just not the 20.5
Kernels 0.1.35 and later (available soon in RawHide) should have this fix; if
these don't fix it, please reopen this bug.