public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: steve.cameron@hp.com
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] 2.5.65, cciss_scsi, scsi error handling
Date: 18 Mar 2003 17:13:24 -0500	[thread overview]
Message-ID: <1048025604.1780.76.camel@mulgrave> (raw)
In-Reply-To: <20030318100658.GA997@zuul.cca.cpqcorp.net>

On Tue, 2003-03-18 at 05:06, Stephen Cameron wrote:
> At least the tape drive still works.  The only scsi devices the
> cciss driver will present to linux are tape drives and medium changers.
> (especially not disks.)
> 
> Is it really accurate in this case to say
> 
>   "ERROR: This is not a safe way to run your SCSI host
>    ERROR: The error handling must be added to this driver"
>
> when the only things the error handlers can do 
> is try to abort commands or try to reset devices or buses...

Yes, since if a command times out or fails for some reason, the driver
will return I/O errors immediately (it could also lead to panics if you
retain a reference to the now completed command inside the driver).

A fix like the one you propose:


> +/* Need at least one of these 2 to keep ../scsi/hosts.c from complaining.
> + * It might be possible to implement the device reset and command aborting
> + * ones in a real way, but host/bus reset can't do anything meaningful. */
> +static int cciss_eh_bus_reset_handler(Scsi_Cmnd *notused)
> +{
> +	/* The bus in question is fabricated by this driver.
> +	 * The real busses are behind the array controller, and the
> +	 * firmware is taking care of it, be it SCSI, or something else.  
> +	 * Resetting THAT from here is DEFINITELY not desirable. */
> +	return FAILED;
> +}
> +static int cciss_eh_host_reset_handler(Scsi_Cmnd *notused)
> +{
> +	/* This is an array controller, not just a dumb scsi controller,
> +	 * resetting the HBA would be extremely bad. */
> +	return FAILED;
> +}
> +

Will simply cause the device to be offlined on the first error.

Are the devices the cciss presents really genuine SCSI devices (which
will have timeouts and report errors)?  In which case, you need proper
error handling.

If they're just figments of the cciss controller imagination and
commands will never error or timeout then perhaps you can get away with
just filling in FAILED returns for a single error handler function.

James



  reply	other threads:[~2003-03-18 22:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-18 10:06 [PATCH] 2.5.65, cciss_scsi, scsi error handling Stephen Cameron
2003-03-18 22:13 ` James Bottomley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-03-18 23:22 Cameron, Steve
2003-03-18 23:34 ` Doug Ledford
2003-03-19 20:32 ` Mike Anderson

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=1048025604.1780.76.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=steve.cameron@hp.com \
    /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