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).
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).
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?).
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.
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.
I'm going to investigate further.
ps
My main kernel for now is 3.10.17-gentoo, all that written above is also
true for this version too.
--
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
