Also, Andries and I have come to the conclusion that INT13(extended)
is not workable at the present time. Do/Will you roll this one out the
door?
Andre Hedrick
The Linux IDE guy
On Thu, 21 Oct 1999, Simon Kirby wrote:
> On Thu, Oct 21, 1999 at 08:44:20PM -0400, Andrew Clausen wrote:
>
> > I was more thinking of using the new INT 0x13 interface, which uses
> > 32-bit values. From Ralph Brown's interrupt list:
> >
> > --------d-1348-------------------------------
> > INT 13 - IBM/MS INT 13 Extensions - GET DRIVE PARAMETERS
> > AH = 48h
> > DL = drive (80h-FFh)
> > DS:SI -> buffer for drive parameters (see #00273)
> > Return: CF clear if successful
> > AH = 00h
> > DS:SI buffer filled
> > CF set on error
> > AH = error code (see #00234)
> > BUG: several different Compaq BIOSes incorrectly report high-numbered
> > drives (such as 90h, B0h, D0h, and F0h) as present, giving
> > them the
> > same geometry as drive 80h; as a workaround, scan through disk
> > numbers, stopping as soon as the number of valid drives
> > encountered
> > equals the value in 0040h:0075h
> > SeeAlso: AH=08h,AH=41h,AH=49h,MEM 0040h:0075h
> >
> > Format of IBM/MS INT 13 Extensions drive parameters:
> > Offset Size Description (Table 00273)
> > 00h WORD (call) size of buffer
> > (001Ah for v1.x, 001Eh for v2.x, 42h for v3.0)
> > (ret) size of returned data
> > 02h WORD information flags (see #00274)
> > 04h DWORD number of physical cylinders on drive
> > 08h DWORD number of physical heads on drive
> > 0Ch DWORD number of physical sectors per track
> > 10h QWORD total number of sectors on drive
> > 18h WORD bytes per sector
>
> Hrm...If this is reliable and hasn't already been implemented, I guess it
> would be worth implementing it. I don't think you'll be able to call int
> 0x13 from userspace very easily, either, so fixing the kernel is probably
> best and easiest. Perhaps Andre Hedrick <andre@suse.com> can help here?
> (He would know much more than me about this stuff. :))
>
> > > >From what I remember also, I thought Linux got geometry information this
> > > way:
> > >
> > > 1. User specified on commad line
> > > 2. The partition table (not sure how)
> > > 3. Its own direct disk probing
> > > 4. INT 0x13
> >
> > I don't think it uses INT 0x13. There's a comment in the source
> > suggesting an implementation.
>
> Hrmm:
>
> /*
> * The only "perfect" way to handle this would be to modify the setup.[cS] code
> * to do BIOS calls Int13h/Fn08h and Int13h/Fn48h to get all of the drive info
> * for us during initialization. I have the necessary docs -- any takers? -ml
> */
> /*
> * I did this, but it doesnt work - there is no reasonable way to find the
> * correspondence between the BIOS numbering of the disks and the Linux
> * numbering. -aeb
> *
> * The code below is bad. One of the problems is that drives 1 and 2
> * may be SCSI disks (even when IDE disks are present), so that
> * the geometry we read here from BIOS is attributed to the wrong disks.
> * Consequently, also the "drive->present = 1" below is a mistake.
> *
> * Eventually the entire routine below should be removed.
> */
>
> It doesn't sound like this would work, either. :)
>
> > > Also, "fdisk" reads this information from the kernel somehow, so you
> > > might want to look at the code for it. :)
> >
> > fdisk (and parted) use the HDIO_GETGEOMETRY ioctl. However, Linux
> > isn't good at detecting the geometry, so the ioctl sometimes returns
> > the wrong geometry.
>
> Hrmm..If this is the case, Linux should be fixed. What kernel version
> are you experimenting with? In what cases does it return the wrong
> geometry, and what geometry does it return instead?
>
> Simon-
>
> [ Stormix Technologies Inc. ][ NetNation Communcations Inc. ]
> [ sim@stormix.com ][ sim@netnation.com ]
> [ Opinions expressed are not necessarily those of my employers. ]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/