Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the
dual Celeron I had, moving all the cards into the new system. One of these
was a Promise PDC20267 with 4 40gb disks attached. The machine would not
boot; I assumed it was the i686-smp kernel and installed a Redhat
7.0-provided i386 kernel. Several hours and a dozen or so boots later, it
looks like when the bios on the PDC20267 is installed, the system hangs
while booting at the point where it would probe C/H/S from the devices
attached to the PDC20267 (they've already been identified by that point)
Short and sweet: The goal is to run 2.2.18+ide.2.2.18.02122001 with the
PDC20267 installed and all the disks attached; I assume this is possible
and I'm missing something obvious, since the controller and disks worked in
the dual Celeron, and I'm hoping someone has an idea what I'm missing.
Long and boring:
-Tried 2.2.18+ide.2.2.18.1209 built for i386, i586, i586tsc, and i686
uniprocessor, all resulted in a system hang at the time when hd{e,f,g,h}
would be probed and C/H/S info printed
-Tried 2.2.18+ide.2.2.18.02122001 built for i586, same result.
-Removed PDC20267, above kernel worked
-Attached PDC20267 and removed disks, above kernel worked
-Tried each of the 2 buses in turn, failed as above
-Tried 2.2.17 without ide patch, specifying ide2=0xac00,0xb002 at boot
time, failed as above
Based on this and noting the PDC20267 didn't install its bios when no
devices were attached to it, I assume that is the contention.
Device identifies itself thus:
Bus 0, device 8, function 0:
Unknown mass storage controller: Promise Technology Unknown device (rev
2).
Vendor id=105a. Device id=4d30.
Medium devsel. IRQ 10. Master Capable. Latency=32.
I/O at 0xac00 [0xac01].
I/O at 0xb000 [0xb001].
I/O at 0xb400 [0xb401].
I/O at 0xb800 [0xb801].
I/O at 0xbc00 [0xbc01].
In <[email protected]> Derrick J Brashear <[email protected]> writes:
>Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the
>dual Celeron I had, moving all the cards into the new system. One of these
>was a Promise PDC20267 with 4 40gb disks attached. The machine would not
>boot; I assumed it was the i686-smp kernel and installed a Redhat
>7.0-provided i386 kernel. Several hours and a dozen or so boots later, it
>looks like when the bios on the PDC20267 is installed, the system hangs
>while booting at the point where it would probe C/H/S from the devices
>attached to the PDC20267 (they've already been identified by that point)
I see the same thing with an ASUS A7V133 motherboard that has a
PDC20265 installed on the motherboard. If I disable the PDC BIOS, the
system boots normally - but trying to use any UDMA mode hangs.
Ordinary mdma2 mode works fine.
So I suspect that the real culprit is the UDMA mode which the BIOS
probably enables - when I boot the the BIOS disabled, the device shows
up as running in pio mode.
All in all, I haven't had much success with the PDC controllers -
both cases I have tried will hang the system when enabling UDMA
(and there is no common hardware involved).
--
Henrik Storner | "ATA100 is another testimony to the fact that
<[email protected]> | pigs can be made to fly given sufficient thrust"
|
| Linux kernel hacker Alan Cox, on IDE drives
In article <[email protected]> you wrote:
> Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the
> dual Celeron I had, moving all the cards into the new system. One of these
> was a Promise PDC20267 with 4 40gb disks attached. The machine would not
> boot; I assumed it was the i686-smp kernel and installed a Redhat
> 7.0-provided i386 kernel. Several hours and a dozen or so boots later, it
> looks like when the bios on the PDC20267 is installed, the system hangs
> while booting at the point where it would probe C/H/S from the devices
> attached to the PDC20267 (they've already been identified by that point)
Your motherboard probably has a VIA chipset. I've been chasing several of
such problems in the last weeks, and fixed most of them for the 2.4 kernel.
Unfortionatly, some PCI cards (TV capture and 3C905C) somehow don't like the
fix.
You can achieve the same effect by setting the PCI tuning in the bios to
conservative settings instead of "optimal"....
Greetings,
Arjan van de Ven