2014-07-31 16:16 GMT+02:00 Hans de Goede <hdegoede@xxxxxxxxxx>: > Hi, > > On 07/31/2014 03:51 PM, Laszlo T. wrote: >>>>>> >>>>>> I tested with lot of values. I'm not totally sure but it looks the 31 >>>>>> is max number where it is still stable to create an ext4 filesystem. >>>>> >>>>> Thanks, that is good to know. Can you try the following patch instead >>>>> of changing can_queue ? : >>>>> >>>>> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c >>>>> index 511b229..6cdc1b9 100644 >>>>> --- a/drivers/usb/storage/uas.c >>>>> +++ b/drivers/usb/storage/uas.c >>>>> @@ -1033,6 +1033,7 @@ static int uas_configure_endpoints(struct uas_dev_info *devinfo) >>>>> 3, 256, GFP_NOIO); >>>>> if (devinfo->qdepth < 0) >>>>> return devinfo->qdepth; >>>>> + devinfo->qdepth = 32; >>>>> devinfo->use_streams = 1; >>>>> } >>>>> >>>>> >>>>> Note that the 32 rather then 31 is on purpose. There is 1 stream reserved >>>>> for non tagged commands, so under normal use a can_queue of 31 will cause >>>>> streams 2-32 to be used (stream addresses start at 1 not 0). >>>>> >>>>> And can you please also do (with the device plugged in): >>>>> >>>>> sudo lsusb -v &> lsusb.log and attach lsusb.log to your next mail? >>>>> >>>>> Then assuming my alternative patch works, I'll write a patch to allow >>>>> overriding max qdepth from a quirk + a quirk for your enclosure. >>>> >>>> Thank you, I will try it tonight. >>>> I've already sent the output of lsusb in my first email: >>>> https://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg46005.html >>> >>> Ah, I forgot about that one. That one however seems to be with the >>> device plugged into a usb-2 port, do you have a machine with a usb-3 >>> port and if so can you do the lsusb with the device plugged into >>> a usb-3 port (*) ? >>> >>> This also raises the question if you've been doing your testing where >>> using 31 seems to fix things with the device plugged into a usb-2 or a >>> usb-3 port ? >>> >>> Note that my patch won't do anything for the device plugged into >>> an usb-2 port, in that case you need to change the qdepth = 256 a >>> few lines higher to qdepth = 32. >>> >>> If you've access to both usb-2 and usb-3 ports, it would be good if you >>> could test with both, and let us know if you you need qdepth = 32 to fix >>> things in both cases. >>> >>> I've just re-read the uas spec and it does not say anything about how to >>> determine the uas bridge's max qdepth when running in usb-2, so maybe >>> rather then making this a quirk we need to play it safe and change >>> the qdepth = 256 to qdepth = 32 unconditionally. In usb-3 mode most >>> bridges don't seem to support more then 16 or 32 as qdepth, chances >>> are that for some implementations the same applies to usb-2 mode. >>> >>> Given the relative low speed of the usb-2 bus a qdepth of 32 or even >>> 16 should be more then enough to get most of the benefits of tcq. >>> >>> Regards, >>> >>> Hans >>> >>> >>> *) usb devices return different descriptors at different speeds >> >> All tests were on usb2. >> I don't have usb3 ports but I will try that at weekend. >> >> I'm curious now, am I the first one who has ever tested uas on usb2? > > Ni, I've tested it myself too, including running an entire distro > with gnome3 from an uas disk. > > I'll also do some more tests with mkfs.ext4 with my uas disk enclosures > as that seems to trigger things for you. But for me so far using usb2 is > not a problem. > > Regards, > > Hans It looks stable with can_queue = 65536 and qdepth = 32 on usb2. Please share you result when you have chance to test with your enclosure. Br, Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
