* READ_CAPACITY_16 vs. READ_CAPACITY_10
@ 2013-09-10 13:56 Oliver Neukum
2013-09-10 17:25 ` Alan Stern
2013-09-12 5:56 ` Hannes Reinecke
0 siblings, 2 replies; 10+ messages in thread
From: Oliver Neukum @ 2013-09-10 13:56 UTC (permalink / raw)
To: hare; +Cc: Alan Stern, linux-scsi
Hi Hannes,
you objected to this patch saying there's a possibilty that
HS devices may also need this feature, which would require
a quirk. Does this mean that the patch is acceptable only
with an additional predefined quirk, or do you insist that all
devices be handled with quirks?
Regards
Oliver
+++ b/drivers/usb/storage/scsiglue.c
@@ -211,8 +211,11 @@ static int slave_configure(struct
scsi_device0*sdev)
/*
* Many devices do not respond properly to READ_CAPACITY_16.
* Tell the SCSI layer to try READ_CAPACITY_10 first.
+ * However some USB 3.0 drive enclosures return capacity
+ * modulo 2TB
*/
- sdev->try_rc_10_first = 1;
+ if (us->pusb_dev->speed < USB_SPEED_SUPER)
+ sdev->try_rc_10_first = 1;
/* assume SPC3 or latter devices support sense size > 18 */
if (sdev->scsi_level > SCSI_SPC_2)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-10 13:56 READ_CAPACITY_16 vs. READ_CAPACITY_10 Oliver Neukum
@ 2013-09-10 17:25 ` Alan Stern
2013-09-10 20:44 ` Oliver Neukum
2013-09-12 5:56 ` Hannes Reinecke
1 sibling, 1 reply; 10+ messages in thread
From: Alan Stern @ 2013-09-10 17:25 UTC (permalink / raw)
To: Oliver Neukum; +Cc: hare, linux-scsi
On Tue, 10 Sep 2013, Oliver Neukum wrote:
> Hi Hannes,
>
> you objected to this patch saying there's a possibilty that
> HS devices may also need this feature, which would require
> a quirk. Does this mean that the patch is acceptable only
> with an additional predefined quirk, or do you insist that all
> devices be handled with quirks?
Indeed, we already know of one or two high-speed devices that suffer
from this bug:
http://marc.info/?l=linux-usb&m=133586313307042&w=2
This may influence your decision. I'm not certain whether it is
important enough to merit a new quirk flag, but people experiencing the
problem may have some strong opinions.
Alan Stern
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-10 17:25 ` Alan Stern
@ 2013-09-10 20:44 ` Oliver Neukum
2013-09-11 14:14 ` Alan Stern
0 siblings, 1 reply; 10+ messages in thread
From: Oliver Neukum @ 2013-09-10 20:44 UTC (permalink / raw)
To: Alan Stern; +Cc: hare, linux-scsi
On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
> On Tue, 10 Sep 2013, Oliver Neukum wrote:
>
> > Hi Hannes,
> >
> > you objected to this patch saying there's a possibilty that
> > HS devices may also need this feature, which would require
> > a quirk. Does this mean that the patch is acceptable only
> > with an additional predefined quirk, or do you insist that all
> > devices be handled with quirks?
>
> Indeed, we already know of one or two high-speed devices that suffer
> from this bug:
>
> http://marc.info/?l=linux-usb&m=133586313307042&w=2
>
> This may influence your decision. I'm not certain whether it is
> important enough to merit a new quirk flag, but people experiencing the
> problem may have some strong opinions.
What is the alternative?
I think we can be sure that no drive enclosure will crash
with READ_CAPACITY_16. I am not sure about card readers.
Does anybody know what Windows does?
Regards
Oliver
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-10 20:44 ` Oliver Neukum
@ 2013-09-11 14:14 ` Alan Stern
2013-09-11 15:05 ` Oliver Neukum
2013-09-12 5:47 ` Hannes Reinecke
0 siblings, 2 replies; 10+ messages in thread
From: Alan Stern @ 2013-09-11 14:14 UTC (permalink / raw)
To: Oliver Neukum; +Cc: hare, linux-scsi
On Tue, 10 Sep 2013, Oliver Neukum wrote:
> On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
> > On Tue, 10 Sep 2013, Oliver Neukum wrote:
> >
> > > Hi Hannes,
> > >
> > > you objected to this patch saying there's a possibilty that
> > > HS devices may also need this feature, which would require
> > > a quirk. Does this mean that the patch is acceptable only
> > > with an additional predefined quirk, or do you insist that all
> > > devices be handled with quirks?
> >
> > Indeed, we already know of one or two high-speed devices that suffer
> > from this bug:
> >
> > http://marc.info/?l=linux-usb&m=133586313307042&w=2
> >
> > This may influence your decision. I'm not certain whether it is
> > important enough to merit a new quirk flag, but people experiencing the
> > problem may have some strong opinions.
>
> What is the alternative?
There are three possibilities: nothing, your proposed patch, and a new
quirk flag. The flag is safest, but also the hardest to maintain.
> I think we can be sure that no drive enclosure will crash
> with READ_CAPACITY_16.
I wouldn't count on it, but I don't know of any examples.
> I am not sure about card readers.
Or flash drives.
> Does anybody know what Windows does?
Not me. It probably varies with different versions of Windows.
Alan Stern
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-11 14:14 ` Alan Stern
@ 2013-09-11 15:05 ` Oliver Neukum
2013-09-11 15:42 ` Alan Stern
2013-09-12 5:47 ` Hannes Reinecke
1 sibling, 1 reply; 10+ messages in thread
From: Oliver Neukum @ 2013-09-11 15:05 UTC (permalink / raw)
To: Alan Stern; +Cc: hare, linux-scsi
On Wed, 2013-09-11 at 10:14 -0400, Alan Stern wrote:
> There are three possibilities: nothing, your proposed patch, and a new
Nothing is feasible only if Windows uses READ_CAPACITY_10.
> quirk flag. The flag is safest, but also the hardest to maintain.
Again the same answer.
> > I think we can be sure that no drive enclosure will crash
> > with READ_CAPACITY_16.
>
> I wouldn't count on it, but I don't know of any examples.
>
> > I am not sure about card readers.
>
> Or flash drives.
>
> > Does anybody know what Windows does?
>
> Not me. It probably varies with different versions of Windows.
I'll try to get a Windows machine for a trace.
Can you suggest a tracer for Win7?
Regards
Oliver
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-11 15:05 ` Oliver Neukum
@ 2013-09-11 15:42 ` Alan Stern
2013-09-11 15:56 ` Steve Magnani
0 siblings, 1 reply; 10+ messages in thread
From: Alan Stern @ 2013-09-11 15:42 UTC (permalink / raw)
To: Oliver Neukum; +Cc: hare, linux-scsi
On Wed, 11 Sep 2013, Oliver Neukum wrote:
> On Wed, 2013-09-11 at 10:14 -0400, Alan Stern wrote:
>
> > There are three possibilities: nothing, your proposed patch, and a new
>
> Nothing is feasible only if Windows uses READ_CAPACITY_10.
It seems clear that your patch isn't feasible either, as it doesn't
help high-speed devices.
> > quirk flag. The flag is safest, but also the hardest to maintain.
>
> Again the same answer.
>
> > > I think we can be sure that no drive enclosure will crash
> > > with READ_CAPACITY_16.
> >
> > I wouldn't count on it, but I don't know of any examples.
> >
> > > I am not sure about card readers.
> >
> > Or flash drives.
> >
> > > Does anybody know what Windows does?
> >
> > Not me. It probably varies with different versions of Windows.
>
> I'll try to get a Windows machine for a trace.
> Can you suggest a tracer for Win7?
I don't know of any, offhand. Maybe Google can help.
Alternatively, you could install Windows 7 in a virtual machine under
Linux and use usbmon.
Alan Stern
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-11 15:42 ` Alan Stern
@ 2013-09-11 15:56 ` Steve Magnani
0 siblings, 0 replies; 10+ messages in thread
From: Steve Magnani @ 2013-09-11 15:56 UTC (permalink / raw)
To: Alan Stern; +Cc: Oliver Neukum, hare, linux-scsi
On Wed, 2013-09-11 at 11:42 -0400, Alan Stern wrote:
> On Wed, 11 Sep 2013, Oliver Neukum wrote:
> >
> > I'll try to get a Windows machine for a trace.
> > Can you suggest a tracer for Win7?
>
> I don't know of any, offhand. Maybe Google can help.
>
> Alternatively, you could install Windows 7 in a virtual machine under
> Linux and use usbmon.
USBPcap can capture Windows USB transactions which Wireshark 1.10 or
later can interpret:
http://desowin.org/usbpcap/
Note, if you're used to WinPCap or usbmon capture integration with
Wireshark this will be an adjustment. You have to run USBPcap from the
command line to do the capture to a file, quit the capture, then open
the file in Wireshark.
I think depending on the options you pass to USBPcap you could end up
with .pcap frames that are larger than Wireshark can handle (i.e., for a
READ(x) transfer of 128 blocks).
Regards,
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-11 14:14 ` Alan Stern
2013-09-11 15:05 ` Oliver Neukum
@ 2013-09-12 5:47 ` Hannes Reinecke
2013-09-16 12:41 ` Oliver Neukum
1 sibling, 1 reply; 10+ messages in thread
From: Hannes Reinecke @ 2013-09-12 5:47 UTC (permalink / raw)
To: Alan Stern; +Cc: Oliver Neukum, linux-scsi
On 09/11/2013 04:14 PM, Alan Stern wrote:
> On Tue, 10 Sep 2013, Oliver Neukum wrote:
>
>> On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
>>> On Tue, 10 Sep 2013, Oliver Neukum wrote:
>>>
>>>> Hi Hannes,
>>>>
>>>> you objected to this patch saying there's a possibilty that
>>>> HS devices may also need this feature, which would require
>>>> a quirk. Does this mean that the patch is acceptable only
>>>> with an additional predefined quirk, or do you insist that all
>>>> devices be handled with quirks?
>>>
>>> Indeed, we already know of one or two high-speed devices that suffer
>>> from this bug:
>>>
>>> http://marc.info/?l=linux-usb&m=133586313307042&w=2
>>>
>>> This may influence your decision. I'm not certain whether it is
>>> important enough to merit a new quirk flag, but people experiencing the
>>> problem may have some strong opinions.
>>
>> What is the alternative?
>
> There are three possibilities: nothing, your proposed patch, and a new
> quirk flag. The flag is safest, but also the hardest to maintain.
>
>> I think we can be sure that no drive enclosure will crash
>> with READ_CAPACITY_16.
>
> I wouldn't count on it, but I don't know of any examples.
>
Me neither. The whole issue just smells of some firmware coders
messing up their stuff. So I would think that other firmwares
might not have this problem.
(But as HS enclosures aren't that common chances are we've hit
the same firmware by chance on every test machine we've had.)
I think it would warrant a quirk approach. Yes, it might be slightly
more coding, but at the same time it's more selective on where it
should trigger.
Also looking at scsiglue.c it would make things quite tricky if
you'd want to _disable_ this feature for HS devices; other firmware
from other vendors might not exhibit this issue after all.
And scsiglue.c already has tons of quirks set, adding one more
doesn't do any harm.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-10 13:56 READ_CAPACITY_16 vs. READ_CAPACITY_10 Oliver Neukum
2013-09-10 17:25 ` Alan Stern
@ 2013-09-12 5:56 ` Hannes Reinecke
1 sibling, 0 replies; 10+ messages in thread
From: Hannes Reinecke @ 2013-09-12 5:56 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Alan Stern, linux-scsi
On 09/10/2013 03:56 PM, Oliver Neukum wrote:
> Hi Hannes,
>
> you objected to this patch saying there's a possibilty that
> HS devices may also need this feature, which would require
> a quirk. Does this mean that the patch is acceptable only
> with an additional predefined quirk, or do you insist that all
> devices be handled with quirks?
>
> Regards
> Oliver
>
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -211,8 +211,11 @@ static int slave_configure(struct
> scsi_device0*sdev)
> /*
> * Many devices do not respond properly to READ_CAPACITY_16.
> * Tell the SCSI layer to try READ_CAPACITY_10 first.
> + * However some USB 3.0 drive enclosures return capacity
> + * modulo 2TB
> */
> - sdev->try_rc_10_first = 1;
> + if (us->pusb_dev->speed < USB_SPEED_SUPER)
> + sdev->try_rc_10_first = 1;
>
> /* assume SPC3 or latter devices support sense size > 18 */
> if (sdev->scsi_level > SCSI_SPC_2)
>
Predefined quirks is okay.
My main objection here is that the original issue most likely is a
buggy firmware, so there is a _very_ good chance that it'll be
resolved in firmware in the near future.
At the same time, other firmwares might continue to not support
READ_CAPACITY_16 while enabling HS.
So both issues really should be kept separate, which'll warrant a
new flag.
Which of course could be set to on per default on HS devices.
As long as we can switch is off again ...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
2013-09-12 5:47 ` Hannes Reinecke
@ 2013-09-16 12:41 ` Oliver Neukum
0 siblings, 0 replies; 10+ messages in thread
From: Oliver Neukum @ 2013-09-16 12:41 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Alan Stern, linux-scsi
On Thu, 2013-09-12 at 07:47 +0200, Hannes Reinecke wrote:
> On 09/11/2013 04:14 PM, Alan Stern wrote:
> > On Tue, 10 Sep 2013, Oliver Neukum wrote:
> >> I think we can be sure that no drive enclosure will crash
> >> with READ_CAPACITY_16.
> >
> > I wouldn't count on it, but I don't know of any examples.
> >
> Me neither. The whole issue just smells of some firmware coders
> messing up their stuff. So I would think that other firmwares
> might not have this problem.
Certainly. But does it matter? We would be happy to always use
READ_CAPACITY_16 first, if it weren't for other buggy firmware.
> (But as HS enclosures aren't that common chances are we've hit
> the same firmware by chance on every test machine we've had.)
>
> I think it would warrant a quirk approach. Yes, it might be slightly
> more coding, but at the same time it's more selective on where it
> should trigger.
Yes and we would for sure miss many cases.
> Also looking at scsiglue.c it would make things quite tricky if
> you'd want to _disable_ this feature for HS devices; other firmware
Just another quirk.
> from other vendors might not exhibit this issue after all.
> And scsiglue.c already has tons of quirks set, adding one more
> doesn't do any harm.
It doesn't do harm if the number of devices to be added is small.
The enclosure works under Windows. So we know that it uses
READ_CAPACITY_16 under some circumstances.
Unfortunately I haven't dug up a Windows box as yet.
However we can realistically hope that the firmwares become
fixed only if Windows _fails_ to use READ_CAPACITY_16 under
some circumstances.
Regards
Oliver
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-09-16 12:41 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-10 13:56 READ_CAPACITY_16 vs. READ_CAPACITY_10 Oliver Neukum
2013-09-10 17:25 ` Alan Stern
2013-09-10 20:44 ` Oliver Neukum
2013-09-11 14:14 ` Alan Stern
2013-09-11 15:05 ` Oliver Neukum
2013-09-11 15:42 ` Alan Stern
2013-09-11 15:56 ` Steve Magnani
2013-09-12 5:47 ` Hannes Reinecke
2013-09-16 12:41 ` Oliver Neukum
2013-09-12 5:56 ` Hannes Reinecke
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).