Date: Fri, 2 Sep 2011 08:53:29 -0700 From: Kevin Oberman <kob6558@gmail.com> To: perryh@pluto.rain.com Cc: dmagda@ee.ryerson.ca, freebsd-stable@freebsd.org, dart@es.net, freebsd@jdc.parodius.com Subject: Re: Unable to shutdown Message-ID: <CAN6yY1ufsm_NOQX2RBJ_COik9P_dTo_2Jbcn2m3EtriHUkQ2aQ@mail.gmail.com> In-Reply-To: <CAN6yY1szj4t1_Ho--6VnhXe9ewjthTTin7auvJAgtem2o5_0aQ@mail.gmail.com> References: <CAN6yY1s3x1ojxh-Dx9Ht=L8M4frohLXcMLNgz%2BzgtBCDodBdsg@mail.gmail.com> <uh78vqd9u8e.fsf@P142.sics.se> <4E5BF15F.9070601@es.net> <CAN6yY1u6ZshVZT2DwaQ2Et7Y1JvNA8q%2BFj5os4SmK4=7=Z77vg@mail.gmail.com> <f0ffdf9eccf14f42ee24f0982bb0fc4b.squirrel@webmail.ee.ryerson.ca> <20110830214832.GA87354@icarus.home.lan> <CAN6yY1upYKW9e3mmED11pTXk%2BVO1KduPy-boWTr7m9S42jUKWw@mail.gmail.com> <20110830234323.GA88936@icarus.home.lan> <CAN6yY1v%2ByqZTkX=XjAoLJWNuf%2Bz6OwR-s2sfdGuGk_RXwBK_VA@mail.gmail.com> <20110831071207.GA95960@icarus.home.lan> <4e5f49fa.2qH1H6gV7TIdZYiD%perryh@pluto.rain.com> <CAN6yY1szj4t1_Ho--6VnhXe9ewjthTTin7auvJAgtem2o5_0aQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 31, 2011 at 8:23 PM, Kevin Oberman <kob6558@gmail.com> wrote: > On Thu, Sep 1, 2011 at 2:01 AM, =A0<perryh@pluto.rain.com> wrote: >> Jeremy Chadwick <freebsd@jdc.parodius.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1ufsm_NOQX2RBJ_COik9P_dTo_2Jbcn2m3EtriHUkQ2aQ>