From owner-freebsd-stable@FreeBSD.ORG Thu Sep 1 02:13:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 603DD106566C for ; Thu, 1 Sep 2011 02:13:30 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 0369C8FC18 for ; Thu, 1 Sep 2011 02:13:29 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p812DMKg085204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Aug 2011 19:13:23 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p812DMF0085203; Wed, 31 Aug 2011 19:13:22 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA26622; Wed, 31 Aug 11 19:01:52 PDT Date: Thu, 01 Sep 2011 02:01:46 -0700 From: perryh@pluto.rain.com To: freebsd@jdc.parodius.com Message-Id: <4e5f49fa.2qH1H6gV7TIdZYiD%perryh@pluto.rain.com> References: <4E5BF15F.9070601@es.net> <20110830214832.GA87354@icarus.home.lan> <20110830234323.GA88936@icarus.home.lan> <20110831071207.GA95960@icarus.home.lan> In-Reply-To: <20110831071207.GA95960@icarus.home.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dmagda@ee.ryerson.ca, freebsd-stable@freebsd.org, dart@es.net Subject: Re: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 02:13:30 -0000 Jeremy Chadwick wrote: > On Tue, Aug 30, 2011 at 11:04:43PM -0700, Kevin Oberman wrote: > > ... the standrad does not specify EXACTLY what triggers a > > transition from standby to ready (PM2 to PM0). Only that it is > > something that requires media access. A write does not > > necessarily require media access if you define "media" as the > > disk platter. > > You're correct -- "media access" could mean, literally, "accessing > the platter" OR it could mean "LBA read/write I/O". Then comes > into question whether or not the drive returning something from > its on-board cache would count as "media access" or not. > > T13 should probably clarify on this point, and this is one I do > not have an answer for myself. I strongly believe "media access" > means "LBA read/write I/O" and regardless if it's data that's in > the on-board cache on the disk or not. I wonder if this behaviour > varies per drive model. Given a standard which is, shall we say, "open to interpretation", I think the liklihood approaches 100% that it has been interpreted differently by different manufacturers -- or even by different firmware authors within a single manufacturer. I would be amazed if the behaviour did _not_ vary among drive models.