All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Douglas Gilbert <dougg@torque.net>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	USB Storage list <usb-storage@lists.one-eyed-alien.net>
Subject: Re: [usb-storage] USB storage devices and SAT
Date: Mon, 04 Aug 2008 11:31:58 +0300	[thread overview]
Message-ID: <4896BE7E.3050405@panasas.com> (raw)
In-Reply-To: <20080804022152.GJ4322@one-eyed-alien.net>

Matthew Dharm wrote:
> On Mon, Aug 04, 2008 at 03:10:04AM +0200, Douglas Gilbert wrote:
>> Alan Stern has already noted to another smartmontools developer
>> that such a change is likely to break some USB storage devices.
>> Perhaps the maximum sense buffer size could be optionally
>> specified per usb storage device. Alternatively the usb mass
>> storage logic could make some dynamic decisions itself.
> 
> To clarify: A great many devices choke (fatally) if asked for sense data
> other than 18 bytes.  Since the first TEST_UNIT_READY will likely require
> sense data, almost every device sees REQUEST_SENSE.
> 
> Personally, I hate having to make dynamic decisions in usb-storage.  The
> more we try to do there, the more likely we are to get it wrong.
> 
> If you've got an app that is sending a command, and you KNOW that command
> should produce >18 bytes of sense data, then there should be a way to
> specify to the SCSI core (and thus get passed to usb-storage) that sense
> data of >18 bytes should be requested.
> 

What?!! The number 18 comes totally from USB land at:
drivers/usb/storage/transport.c:601 via call to scsi_eh_prep_cmnd
Otherwise the entire kernel including scsi-ml and all user applications
request 96 bytes of sense, always.

So there is nothing the SCSI core or application can do about it. 
It is USB fix time I'm afraid.

> Matt
> 

The SAT layer will have to override transport.c/usb_stor_invoke_transport
somehow and make do for bigger REQUEST_SENSE. Or a sense_size param per host,
or per command.

Boaz

  reply	other threads:[~2008-08-04  8:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-04  1:10 USB storage devices and SAT Douglas Gilbert
2008-08-04  1:33 ` James Bottomley
2008-08-04  2:18   ` [usb-storage] " Matthew Dharm
2008-08-04  2:21 ` Matthew Dharm
2008-08-04  8:31   ` Boaz Harrosh [this message]
2008-08-04 15:21     ` Matthew Dharm
2008-08-04 15:51 ` Alan Stern
2008-08-04 17:45   ` [usb-storage] " Matthew Dharm
2008-08-05 11:54     ` Boaz Harrosh
2008-08-05 14:51       ` Alan Stern
2008-08-05 15:10         ` Boaz Harrosh
2008-08-05 15:34         ` Douglas Gilbert
2008-08-05 15:57           ` Boaz Harrosh
2008-08-05 16:09             ` Boaz Harrosh
2008-08-05 17:42             ` matthieu castet
2008-09-07 19:35       ` matthieu castet
2008-09-08  7:27         ` Boaz Harrosh
  -- strict thread matches above, loose matches on Subject: below --
2008-08-04 10:08 castet.matthieu

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=4896BE7E.3050405@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=dougg@torque.net \
    --cc=linux-scsi@vger.kernel.org \
    --cc=usb-storage@lists.one-eyed-alien.net \
    /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.