From owner-svn-src-head@FreeBSD.ORG Fri Dec 10 12:24:43 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39FCC106564A; Fri, 10 Dec 2010 12:24:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id C2ACE8FC18; Fri, 10 Dec 2010 12:24:42 +0000 (UTC) Received: from c122-106-172-0.carlnfd1.nsw.optusnet.com.au (c122-106-172-0.carlnfd1.nsw.optusnet.com.au [122.106.172.0]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oBACORwx002151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 23:24:28 +1100 Date: Fri, 10 Dec 2010 23:24:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Cran In-Reply-To: <20101210085828.780e2d45@core.draftnet> Message-ID: <20101210225049.N1980@besplex.bde.org> References: <201012072046.oB7KkB4L079555@svn.freebsd.org> <4CFEAD09.30904@freebsd.org> <4CFEAFA6.4020103@feral.com> <4CFEB1AD.70906@freebsd.org> <20101208153857.H1428@besplex.bde.org> <20101208225235.501ced0e@core.draftnet> <20101209191657.B1400@besplex.bde.org> <20101209221458.42448075@core.draftnet> <20101210092805.M8539@besplex.bde.org> <20101210085828.780e2d45@core.draftnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon , Bruce Evans , Bruce Cran , svn-src-head@freebsd.org, Matthew Jacob Subject: Re: svn commit: r216269 - head/sys/geom/part X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 12:24:43 -0000 On Fri, 10 Dec 2010, Bruce Cran wrote: > On Fri, 10 Dec 2010 10:12:34 +1100 (EST) > Bruce Evans wrote: > >> 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). > > The BIOS does seem to have complete control over the geometry that > FreeBSD detects. Not exactly. Anything that runs before FreeBSD can change the CHS translation if CHS translation is changable. Then FreeBSD will only detect the geometry set by the BIOS (if the BIOS changed the default) if its initialization doesn't clobber the setting before it is read. Since FreeBSD doesn't care about the geometry, it is only accidental if this happens. It didn't happen between at least 1992 and 2009 in 386BSD or FreeBSD, since the driver always reset the drive first. Now we care less about the geometry than in 1992. > Yes we'll use LBA mode if it's available, but what I'm > talking about is the geometry that gets used for creating disklabels > and the MBR. Since I saw the change in the BIOS reflected in what > FreeBSD detected, it appears the BIOS has control over those values > except when it decides to initially use LBA mode. The current geometry possibly changed by the BIOS is equally useless to the default geometry set by the drive. You cannot know if the BIOS changed it. My BIOSes don't seem to change it -- FreeBSD with GEOM has always reported the default CHS as the "firmware" geometry, but I mostly use versions of ata with the reset, and might not have noticed if this changed (I always configure BIOS to "LBA" CHS mode with H=255 and C=63 if possible, but have never seen the CHS make it to the driver). Newer BIOSes with not-so-old not-so-new drives actually have a better chance of setting the default translation mode to the fake one used in partition tables for old OSes and boot loaders than old ones. First, they won't be using CHS translation to talk to the drive, so they can change the current translation to anything without affection their operation, provided the drive is not so old as to not support changing the translation and not so new as to not support CHS and/or changing it. This also depends on the drive being fairly old, else it cannot be covered by any portable CHS. Second, they might have dropped support for old OSes and boot loaders and not really support CHS except for the limit range that it can cover. Then all OSes and boot loaders on the drive must be either not using CHS or be using the limited range that it can cover. >> 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. > > But the problem is that we _do_ use CHS: we use it to create the MBR > and disklabel. Linux invents a geometry if it can't create one from the > on-disk data; we don't. Even if it can't create on from the on-disk data? FreeBSD doesn't do that now, but used to. bsdBSD still does it. One thing I missed was creating a better default when there is no on-disk data. cam_calc_geometry() is good for that. Bruce