From: Mike Anderson <andmike@us.ibm.com>
To: Andries.Brouwer@cwi.nl
Cc: patmans@us.ibm.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] scsi_error fix
Date: Fri, 7 Mar 2003 13:17:32 -0800 [thread overview]
Message-ID: <20030307211732.GA1148@beaverton.ibm.com> (raw)
In-Reply-To: <UTC200303072019.h27KJXX12872.aeb@smtp.cwi.nl>
Andries.Brouwer@cwi.nl [Andries.Brouwer@cwi.nl] wrote:
> From: Patrick Mansfield <patmans@us.ibm.com>
>
> > [Further discussion and things I did not yet investigate:
> > What was changed to make this fail first in 2.5.63?
> > Experience shows that we get into a loop when something else
> > than SUCCESS is returned here. Probably that is a bug elsewhere.
> > Probably the commands that cause problems should never have been
> > sent in the first place.]
>
> The scsi error handler is also used to retrieve sense data for
> adapters/drivers that do not auto retrieve it. In such cases, it should
> not issue any aborts, resets etc.
>
> Indeed.
>
> Your change effectively disables that support - we never hit the code in
> scsi_eh_get_sense() to request sense. It would be very nice if we could
> fix (or audit) all the scsi drivers, apply your change and remove
> scsi_eh_get_sense, but AFAIK that has not and is not happening.
>
> No. What happened before was that we got into an infinite loop.
> The right action is to read the code, understand why it gets
> into a loop, and fix it. Once that has happened we may decide
> to undo my change. Or we may decide to ask for sense at that very spot.
>
> Today both James and Mike say that they can reproduce the loop,
> so probably they'll fix that part. If not, I'll have a look again.
Sorry about that Patrick. I had sent some mail last might and thought it
went to the list.
Both James and I can reproduce this problem. I was able to reproduce
using a hack to scsi_debug.
The loop problem is related to scsi error handling using the common code
of scsi_queue_insert / scsi_requesT_fn . When a command gets started the
scsi_init_cmd_errh function is called which sets retries to 0.
There maybe another issue with the scsi_eh_get_sense function, but I am
still looking at it.
I believe James is still pursuing a solution also.
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2003-03-07 21:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-07 20:19 [PATCH] scsi_error fix Andries.Brouwer
2003-03-07 21:17 ` Mike Anderson [this message]
2003-03-07 22:20 ` James Bottomley
2003-03-07 22:43 ` Mike Anderson
2003-03-07 22:56 ` James Bottomley
2003-03-09 1:41 ` Osamu Tomita
2003-03-07 23:22 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2003-03-06 23:37 Andries.Brouwer
2003-03-07 1:09 ` Rob Radez
2003-03-07 19:41 ` Patrick Mansfield
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=20030307211732.GA1148@beaverton.ibm.com \
--to=andmike@us.ibm.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.com \
--cc=torvalds@transmeta.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