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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
