Bug 27648

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 
Toshiba XM-6602B.
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
Memory: F4000000-F401FFFF
IRQ: 9
The IDE ATA/ATAPI controller is Intel 82371AB/EB PCI Bus Master, using
I/O: 1480-148f
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
IRQ: 15

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 
for 25834.

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)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.2/0700.html
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 
cat /proc/ide/hde/model
(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.