On Sat, 6 Jun 2015, Mark Hills wrote:
> >> The most striking thing is that the affected system consistently uses
> >~4KB
> >> URBs ("Len: 1"?) for writes.
> >>
> >> Whereas all the other requests seem to be a majority ~60KB URBs and
> >"Len:
> >> 30"
> >
> >What did you use for this monitoring? It isn't usbmon output.
>
> It's wireshark/tshark.
>
> Sorry, I'm new to usbmon and I wasn't able to find a 'standard'
> decoder. I didn't imagine the 't' output was intended for posting to
> the list. Wireshark did feel like a sledgehammer, so let me know if
> there is a preferred format.
In fact, people regularly post usbmon 'u'-format output to the list.
> >I'm puzzled. Have you checked /sys/block/sdc/queue/max_sectors_kb?
>
> It's 120 on the affected system.
Of course. Otherwise the reads would be just as short as the writes...
> >Whatever the reason is, it doesn't seem to be connected with the USB
> >stack.
>
> Ok thanks for your assistance. Unless anyone does have any ideas
> here, I suppose my only option is to start tracing the writes up the
> stack.
I believe the individual writes are created in the block layer.
> I recall there's also a verbose/debug kernel config to usb-storage so
> I might try there. But it may be days/weeks before I'm able to do
> this, so any suggestions in the meantime are warmly welcomed.
Debugging usb-storage won't help. It won't give you any more
useful information than usbmon does already. The usb-storage driver
does not create the commands it sends to devices; it merely relays
commands received from higher up.
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
