From: James Bottomley <James.Bottomley@steeleye.com>
To: Aron Zeh <ARZEH@de.ibm.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
Doug Ledford <dledford@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
patman@beaverton.ibm.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2.5.17] Making SCSI not copy the request structure
Date: Fri, 31 May 2002 09:57:31 -0400 [thread overview]
Message-ID: <200205311357.g4VDvWI10367@localhost.localdomain> (raw)
In-Reply-To: Message from "Aron Zeh" <ARZEH@de.ibm.com> of "Fri, 31 May 2002 13:07:50 +0200." <OFF6A89763.CD0EBEF7-ONC1256BCA.003CD69A@de.ibm.com>
ARZEH@de.ibm.com said:
> I had hoped to be able to reproduce by now, but unfortunately my 2.5
> kernels currently fail to boot on zSeries. I'll try the repro and the
> bit change as soon as that little problem can be alleviated.
Actually, I'm afraid there's more to it than my initial recommendation of just
plugging the elevator queue. Your problem lies in the device_blocked flag,
which gets set when queuecommand returns non-zero and is not reset until an
I/O comes back through scsi_finish_command().
I don't believe the host and device blocking serve any purpose anymore. Also,
with the advent of blocking in the blkdev layer, I think we can even get rid
of the host_self_blocked flag (which is currently only used by the mesh
driver). So I'll look into getting rid of them all.
In the mean time, temporarily you may be able to fix it (and this should work
for 2.4) by manually setting host_blocked to false and running the q->
request_fn(q) from your driver when you detect that the can't accept any
commands condition is alleviated.
James
next parent reply other threads:[~2002-05-31 13:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OFF6A89763.CD0EBEF7-ONC1256BCA.003CD69A@de.ibm.com>
2002-05-31 13:57 ` James Bottomley [this message]
2002-05-31 16:57 [PATCH 2.5.17] Making SCSI not copy the request structure Aron Zeh
-- strict thread matches above, loose matches on Subject: below --
2002-05-31 12:04 Aron Zeh
2002-05-24 9:35 Aron Zeh
2002-05-24 16:44 ` Patrick Mansfield
2002-05-24 7:52 Aron Zeh
2002-05-24 8:34 ` rakesh rakesh
2002-05-24 13:17 ` James Bottomley
2002-05-24 13:00 ` James Bottomley
2002-05-23 9:18 Aron Zeh
2002-05-23 12:44 ` James Bottomley
2002-05-21 23:11 James Bottomley
2002-05-22 22:44 ` Patrick Mansfield
2002-05-22 22:53 ` Doug Ledford
2002-05-23 2:01 ` Alan Cox
2002-05-23 3:14 ` Doug Ledford
2002-05-24 15:32 ` Alan Cox
2002-05-24 15:56 ` James Bottomley
2002-05-23 0:06 ` James Bottomley
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=200205311357.g4VDvWI10367@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=ARZEH@de.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dledford@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=patman@beaverton.ibm.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