linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Higdon <jeremy@sgi.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Burn Alting <burn@goldweb.com.au>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Incorrect response to SK/ASC/ASCQ = x 02/04/01 (becoming ready)
Date: Wed, 25 Aug 2004 19:54:53 -0700	[thread overview]
Message-ID: <20040826025453.GA125799@sgi.com> (raw)
In-Reply-To: <1093275122.1776.52.camel@mulgrave>

On Mon, Aug 23, 2004 at 11:31:57AM -0400, James Bottomley wrote:
> On Sun, 2004-08-22 at 19:56, Burn Alting wrote:
> > How about when disk arrays are booting? Typically, a disk array will
> > quickly present target(s) to the host and then take some time to
> > initialise before being ready for medium access. I assume most disk
> > arrays will present the above sense condition (becoming ready) to all
> > medium access commands until it is ready for medium access.
> 
> If you power off a disc and power it on again, the same thing happens.
> 
> I'd like to distinguish between normal occurrences at start of day which
> we need to handle (like spinning up devices or waiting for them to
> become ready from power on).  And normal occurrences during device
> operation.  The former are handled in the ULD and the latter in the
> mid-layer error handler.
> 
> It's certainly possible to rejig the mid-layer to add an extra delay via
> schedule_delayed_work(), but I'd like to be sure its necessary first,
> since the addition looks to be slightly messy.
> 
> James


I believe that 02/04/01 should be treated like a Busy status.  The
semantics are slightly different, but the action taken by the
initiator is the same: wait a bit and then retry.

I have seen this key/asc/asq before and had to handle it that way.
I believe the device in question was a disk drive that had been
powered on recently.  Disks set to have a variable spinup delay
(based on ID, so that not all disks in a 16-drive box power up at
the same time and overstress a power supply) can return this code
up to a couple of minutes after power on.

jeremy

  parent reply	other threads:[~2004-08-26  2:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-22 16:21 Incorrect response to SK/ASC/ASCQ = x 02/04/01 (becoming ready) Alan Stern
2004-08-22 22:55 ` Nathan Bryant
2004-08-22 23:32 ` James Bottomley
2004-08-22 23:56   ` Burn Alting
2004-08-23 15:31     ` James Bottomley
2004-08-23 17:08       ` Burn Alting
2004-08-26  2:54       ` Jeremy Higdon [this message]
2004-08-26 15:38         ` James Bottomley
2004-08-26 22:36           ` Jeremy Higdon
2004-08-27  0:03             ` Douglas Gilbert
2004-08-26 15:55   ` PATCH: (as355) Fix test for valid sense data present Alan Stern
2004-08-26 16:09     ` James Bottomley
2004-08-26 16:59       ` Alan Stern
2004-08-26 17:27         ` James Bottomley
2004-08-26 19:32           ` Alan Stern
2004-08-26 23:36           ` Douglas Gilbert
2004-08-26 17:20       ` Proposal for fixing READ_CAPACITY Alan Stern
2004-08-23 15:10 ` Incorrect response to SK/ASC/ASCQ = x 02/04/01 (becoming ready) Luben Tuikov
2004-08-23 16:05   ` Nathan Bryant
2004-08-23 18:29     ` Luben Tuikov
2004-08-24 22:04   ` Brian King
  -- strict thread matches above, loose matches on Subject: below --
2004-08-26 15:21 Pat LaVarre
2004-08-26 15:29 ` Pat LaVarre

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=20040826025453.GA125799@sgi.com \
    --to=jeremy@sgi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=burn@goldweb.com.au \
    --cc=linux-scsi@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).