Date: Tue, 18 Mar 1997 00:46:39 +1100 From: Bruce Evans <bde@zeta.org.au> To: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org Cc: bde@zeta.org.au, joerg_wunsch@uriah.heep.sax.de Subject: Re: wd and funky geometry (understood?) Message-ID: <199703171346.AAA13488@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> The problem appears to an inconsistent use of geometry information >for each drive. During IPL, the drive is INITed with parameters from the >BIOS's disk parameter table. This makes sense as I can't imagine any >*other* place from which to get the disk geometry (reliably). From >boot() in /usr/src/sys/i386/boot/biosboot/boot.c: >... > However, in wdattach(), wdgetctlr() is invoked to get the drive's >geometry. It does this by issuing an IDENTIFY command (i.e. READP) >to the drive. The data returned by the command is interpreted as >a wdparams structure: >... >Herein lies the problem: these parameters reflect "the default geometry of >the device" (paraphrased from the ATA specification). However, the BIOS's >geometry may *NOT* agree with the drives "default geometry". For example, >the probe of my IDE drives yields: > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): <Maxtor 7345 AT> > wd0: 329MB (675450 sectors), 790 cyls, 15 heads, 57 S/T, 512 B/S > wdc0: unit 1 (wd1): <MAXTOR LXT-340A> > wd1: 321MB (659232 sectors), 654 cyls, 16 heads, 63 S/T, 512 B/S > >However, *both* drives have a BIOS geometry of 611/16/63. (Sorry, >my ancient BIOS does not support "user configurable" geometries >so this was the closest geometry I could find -- hence the reason What's the problem? The BIOS uses the fudged geometry that you told it, but the FreeBSD driver knows better - there is no reason for it to use a fudged geometry. >Why is all this a problem? I don't *think* it causes any problems >during IPL -- since the drive is INITed with the BIOS geometry >during the boot and then switched to the "default geometry" >during the attach/open. I think that the image loaded from the >disk during boot is small enough that changes to the size/shape >of the first track are safely ignored. (though, on second thought, >I suspect this *can* screw you if your FBSD partition does not >begin at the start of the disk! Comments?) > >However, sharing a partition might be a problem since DOS's >FDISK (which you used to create the DOS partition) will talk >to a disk shaped per the BIOS geometry. Of course you must use a consistently fudged geometry for everything related to the BIOS. >When FBSD takes over, >the geometry of the disk is changed and track/cylinder boundaries >can "move" (e.g., consider my case with a default geometry >of 57 S/C vs. the BIOS's 63 S/C). The FreeBSD is unrelated to the BIOS. It doesn't even notice when the boundaries move. >And, switching to/from DOS can screw you. Consider DOS and >FBSD sharing wd0. FBSD reINITs the drive to use it's default >geometry. Then, you mount a DOS partition FROM THE SAME DRIVE! >The layout of the DOS partition expected the BIOS geometry >yet the disk is now accessed using the FBSD geometry. No problem. If you mount the partition under FreeBSD, msdosfs ignores everything related to geometries. If you reboot and "mount" the partition under DOS, then the BIOS reinitializes the geometry on reboot. >I suspect that LBA *could* be a redeeming grace. However, I don't Nope. >know enough about the *guarantees* within the drive to determine >if a particular sector address will *allways* map to the same >(PHYSICALLY EQUIVALENT) sector regardless of geometry (i.e., >will sector "97" in a 611/16/63 geometry correspond to the >exactl same physical sector when the drive is configured for >790/15/57??) This is already guaranteed as follows: pick a geometry. Any physically reasonable geometry will work with a modern IDE drive (but note that BIOS geometries are usually not physically reasonable with modern BIOSes for modern (non-small) IDE drives). Then issue a WDCC_IDC command to tell the controller to translate using that geometry. Then do all translations from blkno's to C/H/S values using that geometry. The driver could use LBA mode for modern drives, but that would complicate the driver for little or negative benefit - it would still have to do the translation for old drives. >[someone who really *knows* what they are talking about could probably >determine the *real* effects of all this :-( ] Users get confused :-(. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703171346.AAA13488>