On Thu, 9 Dec 2010 19:58:56 +1100 (EST) Bruce Evans <b...@optusnet.com.au> wrote:
> I had understood the ATA_FLAG_54_58 backwards. It tells us if the > drive is not so old that it doesn't support IDENTIFY records for > words 54-58. I think we rarely get here. Drives old enough to use > CHS may be so old that they don't support words 54-58. Only drives > manufactured during a few years or months in the 1990's will support > words 54-58 but not LBA. Maybe I'm misremembering the length of this > time. All modern drives (including ATA-8) seem to support reporting the current CHS geometry, so FreeBSD will use this for the geometry; however since when the BIOS chooses to use LBA mode the "current geometry" words aren't updated I think we use the wrong geometry on modern drives. > I don't like this. If the drive supports CHS, then its geometries for > this should be reported, if CHS reporting is implemented at all. > There are many to choose from :-), but only 1 or 2 (if any) to report > -- the default one and the current one. Capabilities reporting > should make it clear if the default one can be changed. I consider > CHS features to be unimportant, so they should be reported if the > capabilites reporting tries to be complete; otherwise they are > optional. hdparm for Linux always seemed to report more features > than atacontrol. From more testing I've done today it seems that drive manufacturers have ignored the specifications that say certain fields are obsolete: on an ATA-7 drive setting the BIOS mode to CHS and the number of heads to 8 results in word 55 being updated; all the modern (ATA-7 and ATA-8) drives I've tested report words 54-58 as being valid. So should we be using an older version of the spec and printing obsolete fields too? As it is, we don't have a fallback position if a manufacturer does decide to stop supporting CHS. Should we perhaps be using the LBA mode settings (65535/255/63) if the disk is over 8GB? > I don't like removing them depending on the version. atacontrol is > about the only place that you can see CHS without it possibly having > gone through several layers of fakery. Since it appears that disks are still using the CHS fields despite having been obsolete since ATA-7 I guess it makes sense to continue printing them. > Now I see more clearly that these are only the "firmware" = default > parameters. There are also the current parameters in words 54-58. > These are not reported here. One use for reporting them here is > to make it easy to debug whether the kernel code for using them is > ever reached :-). I don't know if a full unfakedparameter struct is > available here for easy printing. If it is, then the capabilities > flag for words 54-58 is in it, and should be used instead of atarev > for deciding whether to print these words (though setting of > capability bits for old drives is as unreliable as setting the > capability words. The driver seems to trust it). We should definitely be printing the current geometry, since that's what the BIOS has configured. > Risky to change this so late. Actually, I have too much experience > with the system generating wrong geometries, and it goes the other > way. I normally run older FreeBSDs which generate the BIOS geometry > of H=255/C=63 which matches all metadata. When I boot -current it > generates H=16/C=63. I get annoyed by disk^Wbsdlabel complaining > about this and more, and can't risk using it to change labels. I had presumed that since bsdlabel(8) says the geometry values are historical that they weren't actually used anywhere. However I now see that it appears that fsck_ffs does interpret the geometry at least for UFS1. > So I'd be happy if you changed this, so everyone sees any problems in > this area :-). Its main inconsistency seems to be that only CAM ad > does it. If I was updating it I'd also update the old ad(4) driver to match. -- Bruce Cran _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
