From owner-svn-src-all@FreeBSD.ORG Fri Dec 10 08:58:39 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E83106566C; Fri, 10 Dec 2010 08:58:39 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 7444C8FC0C; Fri, 10 Dec 2010 08:58:39 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9C39FE717B; Fri, 10 Dec 2010 08:58:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=6pnyK7RsuYXa COrwISLK8A7zG80=; b=fQLXi2IQ8k0lFom0t1DcIaXcS5njkXFbUMfrqxVahOGm 6jrNBaBEiOo5zXp+UeKDdOKnafXxLL82aIVsqnUNJBMMC9qquibToy3ZD8B37f+4 IFtMAX04sXZUBLo9FAdFQ9aKLC9tdVa/of75WVT1POW/9M8Q3AkWe0t2Qdkp9lY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=lM+wIe l2o/VCHyv+1f4Tf3DJVQAd9pOyCaa8Rm4gHlPS85b6nfcWS2XKJAQk4la9L47fPj 7xn4A+dTM2b2KA2rf6VFUAiVRThvQWyGnjC9xC+P0enTskZluUIFCq73l0h4UXzv AEWao2dpGw9FPhx1NFEMxGJI5PrwnIgw+Sch8= Received: from core.draftnet (client-86-27-21-134.glfd.adsl.virginmedia.com [86.27.21.134]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 27848E7174; Fri, 10 Dec 2010 08:58:38 +0000 (GMT) Date: Fri, 10 Dec 2010 08:58:28 +0000 From: Bruce Cran To: Bruce Evans Message-ID: <20101210085828.780e2d45@core.draftnet> In-Reply-To: <20101210092805.M8539@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> X-Mailer: Claws Mail 3.7.7 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon , Bruce Cran , svn-src-head@freebsd.org, Matthew Jacob Subject: Re: svn commit: r216269 - head/sys/geom/part X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 08:58:40 -0000 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. 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 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. -- Bruce Cran