Hi, Felipe Balbi <[email protected]> writes: >> On your testing/next, I see considerable slow down and file >> corruption in mass storage. >> >> After bisecting, this patch seems to be the first one that shows >> problems. The device fails even enumeration here. >> >> I haven't looked in detail at the changes but, do you have any ideas? >> >> I have attached driver logs. > > g_mass_storage doesn't use sglists, so I find this to be unlikely. I'll > test again but I didn't notice any problems on my side.
Few things:
Host sent you a few Resets which I don't know why they're there:
irq/16-dwc3-2849 [002] d..2 45.257835: dwc3_event: event (00000101):
Reset [U0]
[...]
irq/16-dwc3-2849 [002] d..2 45.352847: dwc3_event: event (00000101):
Reset [U0]
[...]
irq/16-dwc3-2849 [002] d..2 45.257835: dwc3_event: event (00000101):
Reset [U0]
[...]
4 requests per endpoint, why so few? To test throughput, I've been using
96 requests per endpoint :-p
file-storage-2848 [003] ...1 45.319500: dwc3_alloc_request: ep1in: req
ffff8ba68ead9ce8 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319505: dwc3_alloc_request: ep1out: req
ffff8ba68eadad68 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319510: dwc3_alloc_request: ep1in: req
ffff8ba68ead9ef8 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319514: dwc3_alloc_request: ep1out: req
ffff8ba68ead98c8 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319519: dwc3_alloc_request: ep1in: req
ffff8ba68eadb9c8 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319524: dwc3_alloc_request: ep1out: req
ffff8ba68eadb5a8 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319528: dwc3_alloc_request: ep1in: req
ffff8ba68eadb188 length 0/0 zsI ==> 0
file-storage-2848 [003] ...1 45.319533: dwc3_alloc_request: ep1out: req
ffff8ba68ead9ad8 length 0/0 zsI ==> 0
In fact, there are no bulk ep transfers on your log. Why's that? What is
the host doing?
--
balbi
signature.asc
Description: PGP signature
