On Thu, 9 Dec 2010, Bruce Cran wrote:
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.
The BIOS has little control over the mode. It can't enforce LBA if the
drive supports CHS. It can't force any particular CHS mode since the
driver may set any CHS mode. ata used to reset the drive in the probe
and in reinit. I think this is a hard reset which restores the default
CHS. I can't see where ata resets now. It is nicely obfuscated using
function pointers. I think it does less resetting. It also has a
soft reset for at least sata, but sata won't be using CHS. Removing of
resets would explain why it now has to use the current CHS (since it
doesn't change the CHS back to the default).
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.
...
From more testing I've done today it seems that drive manufacturers
have ignored the specifications that say certain fields are obsolete:
Obsolete doesn't mean that it is require to be broken.
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
If they support using CHS, and also support changing CHS, then they
have to have these words to report what the change was.
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?
The driver always ignores CHS (except to report it) and uses LBA if
possible. If a manufacturer stops supporting CHS, then the driver
shouldn't notice, but the manufacturer's non-support should include
setting the obsolete fields to 0 (or possibly other specified magic
numbers). It is then up to utilities whether to report these fields
as simply there value or to decrypt their magic values into a CHS-
unsupported flag (I don't know of any actual flag for this). Then
there is the "firmware geometry" reported to GEOM. You could try
changing this to 0/0/0 and see what breaks. CAM for SCSI drives still
invents a geometry to avoid seeing evil here, since SCSI drives have
only had no geometry for about 30 years now.
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.
Not really. Disks aren't users, but may support their use. Drivers
aren't using them, but should be reporting when they are useable and
also their values if use is supported and 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.
Urk. For ffs1, it seems to be rounding important parameters to track
and cylinder boundaries. It divides by d_secpercyl. So you would
soon find that a geometry of 0/0/0 doesn't work :-).
Bruce
_______________________________________________
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"
