Bug 68161
Summary: | Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card. | ||
---|---|---|---|
Product: | Drivers | Reporter: | tatxarata |
Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
Status: | NEW --- | ||
Severity: | normal | CC: | alan, sarah, stern, tatxarata, xhci |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.12.6 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Log when trying to mount card via thunar.
Capture from wireshark's device usbmon when trying to mount card via thunar. Log when I mount and copy file from shell. Capture from wireshark's device usbmon when I mount and copy file from shell. Capture from wireshark's device usbmon when mounting via thunar in USB2.0 port. |
Description
tatxarata
2014-01-04 22:17:24 UTC
Created attachment 120891 [details]
Log when trying to mount card via thunar.
Created attachment 120901 [details]
Capture from wireshark's device usbmon when trying to mount card via thunar.
Created attachment 120911 [details]
Log when I mount and copy file from shell.
Created attachment 120921 [details]
Capture from wireshark's device usbmon when I mount and copy file from shell.
Created attachment 120931 [details]
Capture from wireshark's device usbmon when mounting via thunar in USB2.0 port.
On Sat, Jan 04, 2014 at 10:17:24PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=68161 > > Bug ID: 68161 > Summary: Unstable work of xhci with USB3.0 card reader and > UDMA7 CompactFlash card. Please send this to the linux-usb@vger.kernel.org mailing list. 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 reset occurs 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. Oops.. my bad... It seems like wireshark misses some data while capturing on usbmon device. According to LBA addresses in subsequent SCSI commands it looks like on a request of 240 sectors host really gets from device 240 sectors. On the other hand for each such request in the capture exists only one URB_BULK packet with data and the size of this data covers only 120 sectors (61440 bytes). As a consequence size of capture file is about twice less than size of files transferred to create this capture. In my previous examinations I've took into account only size of URB_BULK packets and missed out the difference between subsequent LBA addresses. For such URB_BULK packets wireshark states "URB length: 122880", "Data length: 61440". Reading of Documentation/usb/usbmon.txt didn't clarified for me what does this mean. Whether this is limitation of usbmon or a feature of wireshark. Sorry for that inconvenience. Does the 3.14 kernel work any better? It includes several changes to xhci-hcd. On 04/09/2014 10:26 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=68161 > > --- Comment #9 from Alan Stern <stern@rowland.harvard.edu> --- > Does the 3.14 kernel work any better? It includes several changes to > xhci-hcd. > I've tested my setup with vanilla kernel version 3.14.1. Nothing changed at all. It's been almost a year since there was any news about this bug. Is it still a problem with the 3.19 or 4.0-rc kernels? |