From: James Bottomley <James.Bottomley@steeleye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>,
Joerg Schilling <schilling@fokus.fraunhofer.de>,
magliery@csb.yale.edu, appro@fy.chalmers.se,
USB development list <linux-usb-devel@lists.sourceforge.net>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [linux-usb-devel] FW: USB 2.0 external hard drive problem
Date: 09 Feb 2004 11:50:13 -0500 [thread overview]
Message-ID: <1076345415.2090.30.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0402091132000.1650-100000@ida.rowland.org>
On Mon, 2004-02-09 at 11:40, Alan Stern wrote:
> In the absence of anything better, we're forced to assume "bad" status
> corresponds to Check Condition...
>
> What do you think, Matt? Should we remove the auto-sense for short
> transfers when we get "good" status? Bearing in mind that it's
> technically legal, but other drivers or programs may not expect it? Also
> bearing in mind that we have no choice but to auto-sense for non-IN
> transfers with the CB transport.
OK, if you want to understand what the mid-layer problem is, look at
scsi_finish_command(). You see in there we set DRIVER_SENSE if we find
any valid sense code in the sense buffer (including NO SENSE)
We will return this to the user as a sense error at various points.
The safest course, if you want to send unsolicited request sense
commands is probably to zero out the sense buffer if you get NO SENSE
back.
James
next prev parent reply other threads:[~2004-02-09 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200402061211.i16CBSIw001678@burner.fokus.fraunhofer.de>
2004-02-06 14:59 ` [linux-usb-devel] FW: USB 2.0 external hard drive problem Alan Stern
2004-02-06 15:24 ` James Bottomley
2004-02-06 20:59 ` Matthew Dharm
2004-02-09 16:40 ` Alan Stern
2004-02-09 16:50 ` James Bottomley [this message]
2004-02-09 21:11 ` Matthew Dharm
2004-02-09 21:30 ` Alan Stern
2004-02-09 22:11 ` Tony Battersby
2004-02-06 15:10 Joerg Schilling
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=1076345415.2090.30.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=appro@fy.chalmers.se \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=magliery@csb.yale.edu \
--cc=mdharm-scsi@one-eyed-alien.net \
--cc=schilling@fokus.fraunhofer.de \
--cc=stern@rowland.harvard.edu \
/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