Hi, On 07/31/2014 01:37 PM, Laszlo T. wrote: > 2014-07-31 12:53 GMT+02:00 Hans de Goede <hdegoede@xxxxxxxxxx>: >> Hi, >> >> On 07/31/2014 12:39 AM, Laszlo T. wrote: >>>>>> Disconnection issues like you are seeing are typical for drawing >>>>>> too much power from the port. Using uas as the dmesg shows you >>>>>> are will allow us to send more commands to the disk at once >>>>>> (which is a good thing, it is faster) and as such will increase >>>>>> power consumption. >>>>> >>>>> Maybe the too much commands freeze the chip. >>>> >>>> That is a testable hypothesis. >>>> This patch shows how to manipulate that number. >>>> You can play with the number to see whether there's >>>> a critical value. >>> >>> 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 -- 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
