All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "James Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Dainius Masiliūnas" <pastas4@gmail.com>,
	"SCSI development list" <linux-scsi@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	"Tom Yan" <tom.ty89@gmail.com>
Subject: Re: Advanced Format SAT devices show incorrect physical block size
Date: Sun, 29 Jan 2017 18:18:37 +0100	[thread overview]
Message-ID: <201701291818.37460@pali> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1701110954060.1900-100000@iolanthe.rowland.org>

[-- Attachment #1: Type: Text/Plain, Size: 2533 bytes --]

On Wednesday 11 January 2017 16:23:29 Alan Stern wrote:
> On Tue, 10 Jan 2017, James Bottomley wrote:
> > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > > In theory, I suppose we could change the kernel so that it would
> > > default to READ CAPACITY(16) for devices that report a SCSI level
> > > >= 3, or something along those lines.  In general we hesitate to
> > > make changes of this sort, because they almost always end up
> > > breaking _some_ devices -- and if that happens then the change
> > > is reverted, with no exceptions.  Linus has a very strict rule
> > > about not breaking working systems.
> > 
> > You shouldn't have to change anything: it already does (otherwise
> > how else would we detect physical exponent for proper SCSI
> > devices) see sd.c:sd_try_rc16_first().  It always returns false
> > for USB because you set sdev->try_rc_10_first
> 
> In fact, this approach probably won't work.  See Bugzilla entries
> #43265 and #43391.  The devices in those reports claimed to be ANSI
> level 4, but they failed anyway.

Seems those devices return capacity 0x7F000000000001 or 0xFF000000000001
Maybe there is some error pattern?

> If you guys want to try the quirk flag, you can apply the patch
> below. Then set the usb-storage module parameter quirks=vvvv:pppp:k
> where vvvv and pppp are the Vendor and Product ID codes for your
> device (as 4 hex digits).
> 
> In the long run, however, this is not a viable approach.  We'd be
> better off with an explicit blacklist.

Ok, so what are next steps? I think that explicit blacklist would be 
needed if "bad" devices is less.

How many bug reports were there?

> Alan Stern
> 
> 
> 
> Index: usb-4.x/drivers/usb/storage/usb.c
> ===================================================================
> --- usb-4.x.orig/drivers/usb/storage/usb.c
> +++ usb-4.x/drivers/usb/storage/usb.c
> @@ -498,7 +498,7 @@ void usb_stor_adjust_quirks(struct usb_d
>  			US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
>  			US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
>  			US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS |
> -			US_FL_ALWAYS_SYNC);
> +			US_FL_ALWAYS_SYNC | US_FL_NEEDS_CAP16);
> 
>  	p = quirks;
>  	while (*p) {
> @@ -551,6 +551,9 @@ void usb_stor_adjust_quirks(struct usb_d
>  		case 'j':
>  			f |= US_FL_NO_REPORT_LUNS;
>  			break;
> +		case 'k':
> +			f |= US_FL_NEEDS_CAP16;
> +			break;
>  		case 'l':
>  			f |= US_FL_NOT_LOCKABLE;
>  			break;

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2017-01-29 17:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201701102031.42361@pali>
2017-01-10 20:02 ` Advanced Format SAT devices show incorrect physical block size Alan Stern
2017-01-10 20:09   ` Dainius Masiliūnas
2017-01-10 20:29     ` Alan Stern
2017-01-10 20:44       ` Dainius Masiliūnas
     [not found]         ` <CABhjJhOp1GB0KXupWhDh-5v-+6N8=qA=rE9L21AANhdN5C0Bxg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-10 21:00           ` Alan Stern
2017-01-10 21:42             ` Dainius Masiliūnas
2017-01-11 14:54               ` Alan Stern
     [not found]             ` <Pine.LNX.4.44L0.1701101551591.2462-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2017-01-10 22:12               ` James Bottomley
2017-01-11 13:33                 ` Pali Rohár
2017-01-11 15:23                 ` Alan Stern
2017-01-29 17:18                   ` Pali Rohár [this message]
2017-01-30 16:17                     ` Alan Stern
     [not found]                       ` <Pine.LNX.4.44L0.1701301055100.2025-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2017-01-30 17:43                         ` Pali Rohár
2017-02-23  9:03                           ` Pali Rohár
     [not found]       ` <Pine.LNX.4.44L0.1701101520510.2462-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2017-01-11 13:36         ` Pali Rohár
2017-01-11 15:10           ` Alan Stern
     [not found]   ` <Pine.LNX.4.44L0.1701101457390.2462-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2017-01-10 20:12     ` Pali Rohár

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=201701291818.37460@pali \
    --to=pali.rohar@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pastas4@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tom.ty89@gmail.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.