Hi,
Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
