From owner-freebsd-stable@FreeBSD.ORG Fri Sep 2 15:53:31 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 11643106564A for ; Fri, 2 Sep 2011 15:53:31 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEA1D8FC17 for ; Fri, 2 Sep 2011 15:53:30 +0000 (UTC) Received: by yxn22 with SMTP id 22so1562531yxn.13 for ; Fri, 02 Sep 2011 08:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xGYgKsFmCcJ6j2jEZf8YILwgLJpBLRsXThREiujGXKY=; b=qdbonk5JZfHOAgSMFAlgNNuVTvYtKfxrFvMyxrvj2Ufs5kHHwBhSVgqPyCtLhAX7w6 mrVqAhkLuHt4KU/0WwqNrzoGlbMEOaBEcxyI3Q8YwPhsQpqUrHbMu2/1tmcI0tIzajnC VXmXd1wrkmf9/oZLZVYeyKllD2nRWKESrtqMk= MIME-Version: 1.0 Received: by 10.43.132.196 with SMTP id hv4mr1058363icc.18.1314978809956; Fri, 02 Sep 2011 08:53:29 -0700 (PDT) Received: by 10.231.149.204 with HTTP; Fri, 2 Sep 2011 08:53:29 -0700 (PDT) In-Reply-To: References: <4E5BF15F.9070601@es.net> <20110830214832.GA87354@icarus.home.lan> <20110830234323.GA88936@icarus.home.lan> <20110831071207.GA95960@icarus.home.lan> <4e5f49fa.2qH1H6gV7TIdZYiD%perryh@pluto.rain.com> Date: Fri, 2 Sep 2011 08:53:29 -0700 Message-ID: From: Kevin Oberman To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dmagda@ee.ryerson.ca, freebsd-stable@freebsd.org, dart@es.net, freebsd@jdc.parodius.com 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: Fri, 02 Sep 2011 15:53:31 -0000 On Wed, Aug 31, 2011 at 8:23 PM, Kevin Oberman wrote: > On Thu, Sep 1, 2011 at 2:01 AM, =A0 wrote: >> 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". =A0Then 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. =A0I 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. =A0I 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. =A0I would be amazed >> if the behaviour did _not_ vary among drive models. > > And, if you tell your firmware writers that they should look for any > technique that > reduces power consumption, I don't doubt that keeping the disk in > standby until there > was a reason to move data from write cache to disk would look good. I wou= ld hope > that they would not make a cache flush lie, but that used to be common > on old ATA > drives. OK. I tried the drive with a UFS file system. I plugged it in and Gnome mounted it. I then ignored it for a while and the LED went from ON to pulsing (bright to dim and back) at about .5Hz. Drive was spun down. I assume it was in STANDBY. (No other state that I can see it being in.) I requested that the drive be unmounted. It behaved the same way as the msd= osfs system. It appeared to have unmounted, but the device entry still was open and the drive was non-reponsive. Interestingly, although an msdosfs system was still mounted, the LED went from slow pulsing to OFF. Attempts to unmount the msodsfs system failed with the LED staying off and the unmount not completing. Still an open connection to the device with the UFS partition (/dev/da0s3). The system was operating normally. If the drive was in STANDBY when the LED was pulsing, what state was it in when th= e LED was off? I then tried to ls a directory on the msdosfs system. The LED came ON and, = after several seconds, I got the listing of the directory followed by a message that the umount of the msdosfs system had failed. When I checked, there were no open connections to the UFS partition. It was fully unmounted. I could also unmount the msdosfs system. So the problem is not unique to msdosfs. I still think the hardware is doing something weird, especially with the LED going off when I attempted to unmount the file system. I may try doing a run with usbdebug and see if that gives any more clues, but I may not find anything that I understand. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com