All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Robert Trace <maillist@farcaster.org>
Cc: Matthias Prager <linux@matthiasprager.de>,
	linux-scsi@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: 'Device not ready' issue on mpt2sas since 3.1.10
Date: Tue, 10 Jul 2012 12:54:48 -0400	[thread overview]
Message-ID: <20120710165448.GE25664@kernel.stglabs.ibm.com> (raw)
In-Reply-To: <4FFB5A0F.30400@farcaster.org>

On Mon, Jul 09, 2012 at 06:24:15PM -0400, Robert Trace wrote:
> On 07/09/2012 04:45 PM, Darrick J. Wong wrote:
> >
> > I suspect that /sys/devices/<bunch of sas topology here>/manage_start_stop = 0
> > for the SATA devices hanging off the SAS controller.
> 
> Yep, looks like you're right.  For my system:
> 
> # cat /sys/block/sd?/device/scsi_disk/*/manage_start_stop
> 1
> 1
> 1
> 1
> 1
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 
> Those first 5 disks are SATA disks on SATA controllers.  The last 8
> disks are SATA disks on the SAS controller.
> 
> > Setting that sysfs
> > attribute to 1 is supposed to enable the SCSI layer to send TUR when it sees
> > "LU not ready", as well as spin down the drives at suspend/poweroff time.
> 
> Setting it to 1 doesn't seem to have made any difference, however.
> 
> # cat /sys/block/sdm/device/scsi_disk/14\:0\:7\:0/manage_start_stop
> 0
> # echo 1 > /sys/block/sdm/device/scsi_disk/14\:0\:7\:/manage_start_stop
> # cat /sys/block/sdm/device/scsi_disk/14\:0\:7\:0/manage_start_stop
> 1
> # hdparm -y /dev/sdm
> 
> /dev/sdm:
>  issuing standby command
> # hdparm -C /dev/sdm
> 
> /dev/sdm:
>  drive state is:  standby
> # dd if=/dev/sdm of=/dev/null bs=512 count=1
> dd: reading `/dev/sdm': Input/output error
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.00117802 s, 0.0 kB/s
> 
> ... and on the scsi logging side, I see the read(10) to the disk which
> immediately returns "Not Ready" and the I/O failure bubbles up the
> chain.  And afterwards, the disk is still asleep.
> 
> # hdparm -C /dev/sdm
> 
> /dev/sdm:
>  drive state is:  standby
> 
> Also, TURs don't appear to actually wake the disk up (should they?).
> The only thing I've found that'll wake the disk up is an explicit START
> UNIT command.

Sorry, I misspoke, manage_start_stop=1 sends START UNIT, not TUR.  Also, it
only manages spindown/up at suspend/resume time, hence the behavior you see.
The relevant source code is sd_start_stop_device() in drivers/scsi/sd.c.

--D
> 
> -- Rob
> 


  parent reply	other threads:[~2012-07-10 16:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 11:19 'Device not ready' issue on mpt2sas since 3.1.10 Matthias Prager
2012-07-09 14:40 ` Matthias Prager
2012-07-09 19:37   ` Robert Trace
2012-07-09 20:45     ` Darrick J. Wong
2012-07-09 22:24       ` Robert Trace
2012-07-10  0:21         ` Matthias Prager
2012-07-10  1:56           ` Robert Trace
2012-07-10 16:54         ` Darrick J. Wong [this message]
2012-07-10  0:12     ` Matthias Prager
2012-07-10  1:51       ` Robert Trace
2012-07-10 23:27         ` Robert Trace
2012-07-11 12:19           ` Matthias Prager
2012-07-11 13:48             ` Matthias Prager
2012-07-17 18:09               ` Tejun Heo
2012-07-17 19:39                 ` Matthias Prager
2012-07-17 20:01                   ` Tejun Heo
2012-07-21 12:15                     ` Matthias Prager
2012-07-22 17:31                       ` Tejun Heo
2012-07-22 23:14                         ` Matthias Prager
2012-07-23 15:26                           ` Tejun Heo
2012-07-24 22:04                             ` Matthias Prager
2012-07-25 10:26                               ` Reddy, Sreekanth
2012-07-25 14:19                         ` James Bottomley
2012-07-25 17:17                           ` Tejun Heo
2012-07-25 19:55                             ` James Bottomley
2012-07-25 23:56                               ` Matthias Prager
2012-07-26 19:16                                 ` Robert Trace
2012-08-16 18:26                               ` Robert Trace
2012-08-16 20:24                                 ` Matthias Prager
2012-08-16 20:33                                   ` Robert Trace
2012-07-25 22:35                         ` tomm
2012-07-26 19:20                           ` Robert Trace
2012-07-09 22:08   ` NeilBrown
2012-07-10  0:03     ` Matthias Prager
2015-11-27 10:28 Felix Matouschek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120710165448.GE25664@kernel.stglabs.ibm.com \
    --to=djwong@us.ibm.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@matthiasprager.de \
    --cc=maillist@farcaster.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.