> 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/