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. Thanks & Regards, Hans -- 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
