gwr@linus.UUCP (Gordon W. Ross) (01/12/90)
In article <46.25AC0731@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: [ Describes problem with WD 1004-27X providing incorrect parameters in response to BIOS int 0x13, function 0x0f (get disk parameters). Here Mark Unangst quotes Western Digital engineer, Ashley Lo: -GWR ] > [ Mr. Lo ] says this is a known property [ bug? ] of the controller. > He says that instead of using INT 13, you should use INT 41. The > vector for INT 41 is actually a pointer to [ a table describing ] > the structure of the fixed disk. [ Yes, int 0x41 points to table for HD 0, int 0x46 for HD 1. -GWR ] I agree that the data pointed to by in 0x41 is a better source for hard disk geometry information. The trick is to capture the desired information before minix overwrites all the interrupt vectors or the disk parameter table. By the way, both Western Digital and Adaptec ESDI controllers (for the AT) do indeed install a modified disk parameter table and point int 0x41 to it. The greatest advantage of using the data pointed to by int 0x41 is that the number of cylinders stored there can be a full 16-bit quantity. The BIOS int 0x13, (ax=0f) function returns garbage if it finds ( *((int *)(0x41*4)) > 1024 ). I would like a boot program that captures all the useful information from the BIOS data areas and int vectors (like HD geometry, etc.) and then passes these into the kernel at start-up time. Nicer still would be to have a boot program that knows just enough to read the files "kernel,mm,fs" so we wouldn't need "build" or a boot partition. (It could use BIOS calls _just_ for loading these files.) I'm considering working on this. ( Warning: Here begins the lofty dreams :-) Ideally, I'd like to have the minix partitioning and file-system data structures be compatible with Sys.V/386 so I could mount those file systems on minix (it would make cross-development easier). Unfortunately, rewriting the minix partitioning scheme would require extensive changes to minix. I don't think I want to do it (yet). UNIX Sys.V/386 uses a two-level partition scheme. The primary boot sector on the hard disk contains the four-entry partition table we all know and love (only 10-bit cylinder numbers, etc, etc.). One of these (fdisk) partitions contains a UNIX "volume" which is further sub-divided using its own partition scheme (called a "volume table of contents" or VTOC). The UNIX partitions (VTOC entries) are manipulated with "mkpart" and the fdisk partition table is manipulated with fdisk. Interestingly, UNIX partitions (VTOC entries) do not have to be restricted to the UNIX volume; I have an entry in the UNIX partition table that corresponds to the (small) DOS volume (fdisk partition) residing on the first hundred cylinders of the disk. There are other VTOC entries for the "whole UNIX volume", root, swap, and usr. It appears that the VTOC entries can map onto arbitrary regions of the disk as long as the regions start and end on cylinder boundaries. I think this scheme is a good way to get around the limitations of the fdisk partition table. I wonder if Minix could use such a scheme. -- Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr Burlington Road, Bedford, MA 01730 (617) 271-3205