2.4.20 SMP, a PDC20269, and a huge Maxtor disk. Am I doomed?

In the aftermath of a horrible crash (one minute all was well, the next minute all the active ext3 filesystems behaved like they'd been run through a cheese grater), I've installed a 200GB Maxtor drive, and a Promise Ultra133 TX2 card to let me actually use all of it.

The mobo BIOS doesn't speak 48-bit LBA, so it sees a 137 GB drive. That's fine, I'm guessing, since (I'm told) Linux doesn't get its information from the BIOS.

Windows 2000 sees the whole drive, and uses it with no problems. (Using Promise's supplied drivers.) I mention this only to point out that there doesn't /seem/ to be anything physically wrong with the drive, the card, the cable, etc.

So, for starters:

Booting 2.4.20 with "ide2=0x10d8,0x10d2" lets me see the new drive, along with a smaller drive on the same channel as slave:

    PDC20269: IDE controller on PCI bus 00 dev 48
    PDC20269: chipset revision 2
    PDC20269: not 100% native mode: will probe irqs later
    PDC20269: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode.
    PDC20269: FORCING BURST BIT 0x08 -> 0x09 ACTIVE
        ide2: BM-DMA at 0x10b0-0x10b7, BIOS settings: hde:pio, hdf:pio
    hde: Maxtor 6Y200P0, ATA DISK drive
    hdf: WDC WD600BB-00CAA1, ATA DISK drive
    ide2 at 0x10d8-0x10df,0x10d2 on irq 5
    blk: queue c037fdcc, I/O limit 4095Mb (mask 0xffffffff)
    hde: 398297088 sectors (203928 MB) w/7936KiB Cache, CHS=24792/255/63, UDMA(133)
    blk: queue c037ff18, I/O limit 4095Mb (mask 0xffffffff)
    hdf: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=116301/16/63, UDMA(100)

Now, dmesg shows that both hde and hdf are in PIO mode, but hdparm -I reports that the smaller/older drive is using udma5, and the huge drive is using udma6. Which is also what the PDC20269 card-BIOS reports during system boot. So I'm assuming that they really are using DMA.

The problem:

At seemingly random times, these occur:

    May 22 03:11:02 fenric kernel: hde: lost interrupt
    May 22 03:11:02 fenric kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
    May 22 03:11:02 fenric kernel: hde: drive not ready for command

and

    May 22 04:34:11 fenric kernel: hde: write_intr error1: nr_sectors=1, stat=0x51
    May 22 04:34:11 fenric kernel: hde: write_intr: status=0x51 { DriveReady SeekComplete Error }
    May 22 04:34:11 fenric kernel: hde: write_intr: error=0x04 { DriveStatusError }

Which leads to all kinds of problems, especially ifit happens during boot (system hangs).

Recall that this doesn't happen under win2k, so presumably (?) the hardware is not at fault.

Anybody have any suggestions as to what I can do to prevent/solve this? I will cheerfully give more information, and a summary writeup if I ever get it working properly.

(Please cc me; I can't keep up with the list mail so I'm not subscribed.)

Phil

What you don't know can hurt you, only you won't know it.

I believe LBA48 was introduced in 2.4.21-pre. Try 2.4.21-rc2 and see what happens.

Joe

I know that LBA48 wasn't in the 2.4.19 kernel that was on the boot/installation media I was using; cfdisk and everything else only saw the 137. Once I installed 2.4.20, the kernel and all the tools can see the whole drive; just the BIOS listing is still wrong.

(Well, can't boot off the drive with GRUB in the MBR. So there may still be something wrong there. Lose2K can boot from that drive, but not the latest GRUB.)

I will try to give .21-rc2 a spin before I go out of town next week. Thanks!

Phil

If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

My (limited) understanding is that they /should/ (i.e., according to theory) be able to, but that they might not /ought/ to (i.e., what the kernel actually supports). I've been meaning to get another ide cable anyway. :-)

No ERRs at all here.

I am beginning to notice a pattern: if the system is soft-rebooted, the errors in my oridinal email almost always occur during the boot sequence (which either hangs the system, or OOPSes the kernel). Driving over to that building, reaching down and pushing the reset button hasn't (yet) had a problem. I'll try to keep notes during the upcoming inevitable crashes.

Tyan Tiger MP, the S2460 model.

Phil

If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams