From: James Bottomley <James.Bottomley@SteelEye.com>
To: Lan Tran <transter@gmail.com>
Cc: Douglas Gilbert <dougg@torque.net>,
"Qi, Yanling" <yanling.qi@engenio.com>, Dave Olien <dmo@osdl.org>,
Tim Pepper <tpepper@gmail.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: Question about Request Sense case in scsi_lib.c
Date: 14 Oct 2004 10:25:22 -0500 [thread overview]
Message-ID: <1097767531.1717.20.camel@mulgrave> (raw)
In-Reply-To: <ac71172a0410132349715aa9b4@mail.gmail.com>
On Thu, 2004-10-14 at 01:49, Lan Tran wrote:
> And it was due to the fact that when a bio is sent down to the
> mid-layer, it would come back with another bio chained to it, so when
> the original bio was retried, the number of segments that were mapped
> (i.e. 2, one from each bio) did not match the value stored in
> cmd->use_sg (i.e. 1).
This sounds a bit unlikely, since the SCSI layer never deals with bios
per se, it merely maps a request (which is a collection of bios). What
was the evidence that this was happening?
I can see the reverse being true: the scsi request is partially complete
when requeued, so some of the bios are fully complete and somehow this
causes a miscalculation in the segments. However, the miscalculation
has to be that we undercount the number of needed request slots, and
this looks hard to do.
> I still haven't figured out why chained bios
> from indepedent IO requests are returned from the mid-layer ... but
> may be a similar issue you're seeing here?
It sounds similar. The problem seems to be in requeuing somehow. I'm
going to dig out my old requeueing simulator and see if I can reproduce
it.
James
next prev parent reply other threads:[~2004-10-14 15:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53CF1076699CD711B7DD0002A51363F1072A6E3A@exw-ks.ks.lsil.com>
2004-10-13 21:46 ` Question about Request Sense case in scsi_lib.c 'Dave Olien'
2004-10-13 21:56 ` James Bottomley
2004-10-13 22:09 ` 'Dave Olien'
2004-10-14 17:52 ` 'Dave Olien'
2004-10-14 18:05 ` James Bottomley
2004-10-14 20:39 ` James Bottomley
2004-10-14 0:30 ` Douglas Gilbert
2004-10-14 6:49 ` Lan Tran
2004-10-14 15:25 ` James Bottomley [this message]
2004-10-12 0:00 Dave Olien
[not found] ` <eada2a07041012092973d35415@mail.gmail.com>
2004-10-12 16:31 ` Tim Pepper
2004-10-12 16:59 ` Dave Olien
2004-10-12 17:13 ` James Bottomley
2004-10-12 17:59 ` Dave Olien
2004-10-12 20:13 ` Patrick Mansfield
2004-10-12 20:44 ` Dave Olien
2004-10-13 2:10 ` Douglas Gilbert
2004-10-13 17:56 ` Dave Olien
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=1097767531.1717.20.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=dmo@osdl.org \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=tpepper@gmail.com \
--cc=transter@gmail.com \
--cc=yanling.qi@engenio.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 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.