Re: [patch-required!] Recent kernels show problems in handling VERY large HDs

From: Andries Brouwer (aeb@veritas.com)
Date: Sat Sep 09 2000 - 10:52:20 EDT

  • Next message: Daniel Phillips: "Re: [RFC] Changes file [was Re: modules directory]"

    On Fri, Sep 08, 2000 at 10:19:17AM +0200, Andreas Eibach wrote
    about his problems with a large disk:

    > Motherboard GA-586 SG w/AWARD BIOS 4.51PG
    > (no updates available anymore from the manufacturer! 586sg
    > BIOS rev. is 1.15)
    > Maxtor 60 GB hard drive:
    > - Capacity Limitation Jumper J46 APPLIED
    > (otherwise BIOS does not recognize the HD at all!)
    > (note: this lets the HD look like a 32 GB one, causing
    > total confusion with the kernel)
    > - EZDrive (aka MaxBlast) APPLIED (as _prescribed_ by original
    > documentation for older BIOSes)

    Interesting. So far I have been able to help three or four people
    with a similar setup, but without EZDrive.

    The present theory is:
    (i) AWARD BIOS 4.51PG crashes when it sees a disk larger than 32 GB.
    (ii) Applying the J46 jumper is equivalent to a SETMAX command
    and turns the disk into a 32 GB one. (The precise effect depends
    on the model. Early models also require a utility JUMPON.EXE.)
    This allows one to boot.
    (iii) EZDrive/MaxBlast or Linux can issue a SETMAX command to get
    full capacity again.

    By separate mail I'll send you a setmax utility, so that you
    can play a bit with these things.

    (I cannot really release utilities like setmax before the ioctl
    code in ide.c has been adapted very slightly. Will produce a patch
    if I have time later this evening.)

    > NOT TESTED YET: 2.2.17 (should I give it a try?)

    It won't be better.

    > Util-Linux 2.9f (from the distribution)
    > (Note: I've got latest 2.10o tarball here now, one of my suspects
    > causing the errors below was Fdisk at first)

    With large disks it is always good to have a recent fdisk.
    (Forgot whether 2.9f is too old.) But your problem is elsewhere.

    > Linux version 2.4.0-test4 (root@janus) (gcc version egcs-2.91.66
    > 19990314/Linux (egcs-1.1.2 release)) #2 Wed Sep 6 16:38:45 MEST 2000

    > Kernel command line: root=/dev/hdc11 ro single BOOT_IMAGE=bzi_240

    > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
    > SIS5513: IDE controller on PCI bus 00 dev 01
    > SIS5513: chipset revision 208
    > SIS5513: not 100% native mode: will probe irqs later
    > SiS5591
    > ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:pio, hdb:pio
    > ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:pio, hdd:pio
    > hda: Maxtor 96147U8, ATA DISK drive
    > hdb: CD-532E-A, ATAPI CDROM drive
    > hdc: IBM-DTTA-350840, ATA DISK drive
    > hdd: ST33232A, ATA DISK drive
    > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    > ide1 at 0x170-0x177,0x376 on irq 15
    > hda: 120060864 sectors (61471 MB) w/2048KiB Cache, CHS=7473/255/63, UDMA(33)

    > Partition check:
    > hda:hda: timeout waiting for DMA
    > ide_dmaproc: chipset supported ide_dma_timeout func only: 14
    > hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
    > hda: status timeout: status=0xd8 { Busy }
    >
    > OUCH...
    >
    > hda: DMA disabled
    > hda: drive not ready for command
    >
    > OUCHIE...
    >
    > ide0: reset: success
    > [EZD] [remap 0->1] [7473/255/63] hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9
    > hda10 hda11 hda12hda: read_intr: status=0x59 { DriveReady SeekComplete
    > DataRequest Error }
    > hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
    > hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
    > hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
    > hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

    This is clear: the kernel tries to read sector 71987265, that
    is 71987265*512=36857479680 bytes (37 GB) from the start, but
    the disk was clipped to 32 GB, so the disk reports that it
    cannot find such a sector: DriveReady SeekComplete SectorIdNotFound.

    Apparently you have been able to partition the disk.
    Was that under Linux?

    What interests me: did you boot Linux via MaxBlast?
    In that case I would have expected that MaxBlast already
    had unlocked the upper part of the disk.

    Andries
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Sat Sep 09 2000 - 11:01:15 EDT