lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 12 Oct 2008 16:55:45 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Tejun Heo <htejun@...il.com>
Cc:	Christian Mueller <Christian.Mueller@....com>,
	Bruce Allen <ballen@...vity.phys.uwm.edu>,
	Smartmontools Mailing List 
	<smartmontools-support@...ts.sourceforge.net>,
	LKML <linux-kernel@...r.kernel.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Mikael Pettersson <mikpe@...uu.se>
Subject: Re: [smartmontools-support] inactive SATA drives won't stay in standby
 or sleep, PATA models did. (fwd)

Tejun Heo writes:
 > (cc'ing linux-ide and Mikael Pettersson)
 > 
 > Christian Mueller wrote:
 > > The messages I saw on the screen.
 > 
 > If the drive doesn't wake up and times out the smart command while
 > suspended (which probably is a bug in the firmware but it also can be
 > the controller's fault), then after the timeout, the driver should kick
 > in and reset the drive which will wake up the device and retry the
 > command.  It's not the prettiest picture but it's still gonna work.  In
 > Linda's case, it looks like the controller (sata_promise) went bonkers
 > on hardreset and requires power cycle to get back to working state.
 > That's why I asked Linda to try another controller.
 > 
 > Anyways, if you're seeing a similar problem, the driver or controller
 > probably can't do proper reset after timeout and I can't really help
 > with SAS driver on FreeBSD.  :-P
 > 
 > Mikael, the original thread is the following.
 > 
 >   http://article.gmane.org/gmane.linux.utilities.smartmontools/5842
 > 
 > Any ideas why hardreset doesn't work after SMART command timed out?

I've looked at the above posting and tried to reproduce the problem.

Linda wrote that "smartctl -n standby -A <device>" sometimes wakes
the device up, even though it shouldn't. On my Promise test box
(FC6 user-space with kernel 2.6.27 and smartmontools-5.37-1.2.fc6,
I put my test disks in standby with "hdparm -y /dev/sdb", and then
ran numerous "smartctl -n standby -A /dev/sdb -d ata" commands.
smartctl always noticed the standby state and never woke any disk.

I then dropped the "-n standby" to observe the wakeup behaviour.
On one disk (Seagate Barracuda 7200.9) the wakeups were completely
reliable with no signs of timeouts or libata EH activity.
On another disk (Hitachi Deskstar HDS722525VLSA80) the first one or
two times I ran "smartctl -A /dev/sdb -d ata" when the disk was in
standby it would wake up ok, but the next time it would suffer from
timeouts, failed COMRESETs, and eventually libata would disable the port.
When reloading sata_promise that port would fail detection but other
ports would be ok.

So I suspect two issues:
- smartctl -n standby waking Linda's disks from standby is probably
  a disk firmware issue or a smartctl issue. I see no evidence that
  sata_promise is to blame for that.
- hardreset in sata_promise seems broken. I'll take a closer look
  at that in about a week's time (I'll be busy with other work the
  next couple of days).

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ