linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
	SCSI development list <linux-scsi@vger.kernel.org>,
	USB Storage list <usb-storage@lists.one-eyed-alien.net>
Subject: Re: Handling erroneous READ CAPACITY response in sd.c
Date: Mon, 08 Nov 2004 13:55:19 -0500	[thread overview]
Message-ID: <418FC117.1040207@adaptec.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0411051059540.834-100000@ida.rowland.org>

Alan Stern wrote:
> Everything we've tried for detecting too-high-by-one READ CAPACITY
> responses has failed on one device or another.  I can't think of any way
> to detect the error at runtime, short of actually trying to read the last
> sector.  And that is not a good tactic because it will quite likely leave
> the device is some non-resettable hung-up state.  Even the heuristic that
> USB devices will always have an even number of sectors turns out to be
> wrong for the Apple iPod.
> 
> There doesn't seem to be anything left but blacklisting.  This could be
> done at the SCSI level or the usb-storage level.  It turns out there's
> actually an advantage to putting the entries in the usb-storage list:  In
> many cases a vendor will use a USB interface chip from another company,
> changing the vendor name stored in the INQUIRY data but leaving the USB
> vendor ID alone (so it reflects the chip designer, not the drive seller).  
> This means that a single USB blacklist could cover a range of devices that
> would require multiple SCSI blacklist entries.  I've actually seen
> something like this happen in a different context (the Panasonic DMC-LCx
> cameras with internal interfaces by Matsushita have different Product
> strings in their INQUIRY data but the same Product ID in their USB
> descriptors).
> 
> On the other hand, the adjustment of the READ CAPACITY value should still 
> be moved to sd.c from usb-storage.  This can be implemented easily enough 
> by adding a bitflag to the scsi_device structure; the flag could be set 
> either by a SCSI blist entry or by usb-storage in its slave_configure 
> routine.  The flag would tell sd_read_capacity to decrement the number of 
> sectors it receives from the device.

This sounds good.  Just to clarify: if we blacklist in usb-storage, then
I think there's no need to also blacklist in SCSI Core as well.  Let sd
use the flag to decrement the Returned LBA (effectively assign Returned
LBA to capacity rather than increment it and then assign it.)

	Luben







  parent reply	other threads:[~2004-11-08 18:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-15 19:19 Handling erroneous READ CAPACITY response in sd.c Alan Stern
2004-10-19 20:58 ` Luben Tuikov
2004-10-19 21:52   ` Alan Stern
2004-10-20 12:40     ` Luben Tuikov
2004-10-20 15:48       ` Alan Stern
2004-10-24 12:34         ` Eero Volotinen
2004-10-25 19:41           ` Alan Stern
2004-10-25 20:27             ` Luben Tuikov
2004-10-25 20:08           ` Luben Tuikov
     [not found]             ` <417D6123.4060902@ping-viini.org>
2004-10-25 20:55               ` Luben Tuikov
2004-11-05 16:18       ` Alan Stern
2004-11-05 18:06         ` Matthew Dharm
2004-11-05 18:34           ` Alan Stern
2004-11-05 18:44           ` [usb-storage] " Andries Brouwer
2004-11-05 21:38             ` Alan Stern
2004-11-05 21:59               ` Andries Brouwer
2004-11-08 18:55         ` Luben Tuikov [this message]
2004-11-08 21:03           ` Alan Stern
2004-11-08 21:35             ` Luben Tuikov
2004-11-08 22:04             ` Matthew Dharm
2004-11-08 22:08               ` Alan Stern
2004-10-20 13:28     ` Luben Tuikov
     [not found] <417AFDA5.5080806@micro.ee.nthu.edu.tw>
2004-10-24 17:11 ` Alan Stern
2004-10-25 21:54   ` Darsen
2004-10-26 14:43     ` Alan Stern
     [not found] <417F6412.90000@micro.ee.nthu.edu.tw>
2004-10-27 19:11 ` Alan Stern
2004-10-29 14:22   ` Darsen
2004-10-29 16:46     ` Alan Stern

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=418FC117.1040207@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=stern@rowland.harvard.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).