Unable to shutdown

Kevin Oberman kob6558 at gmail.com
Fri Sep 2 15:53:31 UTC 2011

On Wed, Aug 31, 2011 at 8:23 PM, Kevin Oberman <kob6558 at gmail.com> wrote:
> On Thu, Sep 1, 2011 at 2:01 AM,  <perryh at pluto.rain.com> wrote:
>> Jeremy Chadwick <freebsd at 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".  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.
> 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 would 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 msdosfs
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 the 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.
R. Kevin Oberman, Network Engineer - Retired
E-mail: kob6558 at gmail.com

More information about the freebsd-stable mailing list