Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 h...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 h...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: READ_CAPACITY_16 vs. READ_CAPACITY_10
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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
