On Wed, 8 Jan 2014, tatxarata wrote: > Since reporting this bug I've invested some time to get myself familiar > with USB protocol and analyzed attached capture files. It seems like > device resetoccurs after device returns urb_status=-75 (-EOVERFLOW). Yes. The EOVERFLOW error is what causes the driver to do a reset. > This can be seen in attachment > https://bugzilla.kernel.org/attachment.cgi?id=120901 in packet #1987. > Also I've noticed that host tries to read device by chunks of 240 > sectors while device returns on each query no more than 120 sectors > (61440 bytes). That's not true in the log file you just mentioned. See packet #1955. > From traffic it is clearly seen that EOVERFLOW occurs after the device > is already mounted and while software tries to browse it's content. > When I do something like 'dd if=/dev/sdb of=/dev/null' where sdb is CF > card or mount and copy with shell commands host<->device communication > scheme is the same (240 sectors requested, 120 returned), but this > doesn't lead to EOVERFLOW. In that cases read speed is at about 80Mb/s. > So I suppose that something wrong happens only while software like > thunar or midnight commander tries to browse the contents of card (maybe > parallel threads trying to access card simultaneously?). That wouldn't matter. usb-storage serializes accesses to the device. > With that knowledge I've tried to tweak some device parameters in /sys > filesystem. When I put value 60 in /sys/block/sd?/queue/max_sectors_kb > then all operates correctly without any resets. However in this case > read speed of card drops down by factor of two at around 40Mb/s. > > When I set max_sectors_kb to 64 then device does reset upon mount in > thunar, however, surprisingly, this doesn't lead to dropping of device > mount, like in case of default value of 120. In this case read speed is > at about 89.5Mb/s, as expected by card specs. So I've added udev rule > that corrects value of max_sectors_kb to 64 upon device connection. For > now I can live with this 10 seconds latency of device mounting if latter > it works properly. However I think that the reason of this issue must be > clarified and fixed. It seems like a bug in the device. > Also tried to set queue/scheduler to noop with no effect. > > In case of USB2.0 host<->device traffic looks pretty the same way as in > case of USB3.0. Host also tries to read device by chunks of 240 sectors > and device returns only 120. However for some reason this doesn't lead > to EOVERFLOW. > > Main difference I've managed to find between usb 2.0 and 3.0 traffic is > the device initialization. In case of 3.0 there are some > CLEAR_FEATURE/SET_FEATURE requests that are missing in case of 2.0, so > maybe device operates differently by that reason. Maybe, but I doubt it. Those requests are mostly concerned with Link Power Management. What happens if you connect the card reader to a USB-3 port using a USB-2 cable? Alan Stern -- 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
