Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: >> 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 > > Any trick to get it to do that? We haven't really used the > g_mass_storage for performance testing yet. Change to CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS 115 config USB_GADGET_STORAGE_NUM_BUFFERS 116 int "Number of storage pipeline buffers" 117 range 2 256 118 default 2 119 help 120 Usually 2 buffers are enough to establish a good buffering 121 pipeline. The number may be increased in order to compensate 122 for a bursty VFS behaviour. For instance there may be CPU wake up 123 latencies that makes the VFS to appear bursty in a system with 124 an CPU on-demand governor. Especially if DMA is doing IO to 125 offload the CPU. In this case the CPU will go into power 126 save often and spin up occasionally to move data within VFS. 127 If selecting USB_GADGET_DEBUG_FILES this value may be set by 128 a module parameter as well. 129 If unsure, say 2. -- balbi
Attachment:
signature.asc
Description: PGP signature
