Hi Andy, andy_purcell@xxxxxxxxxxxx writes: > Hello Felipe, > > I am not using DWC3. oh, okay :-) > I have new information about the problem. > The context was this: > 1) device boots > 2) some usb transfers happen, all are OK > 3) a device app runs to completion (USB quiescent during this time, no USB transfers required) > 4) the controlling PC starts a 4 KByte USB transfer to the device, but this transfer does not finish. Only 3 Kbytes are ACK'd by the device. > (A USB analyzer shows the host trying to send more, but the device persistently NAK's) > > If step (3) is omitted, everything works fine. What do you mean by "device app runs to completion"? What is the "device app"? Is it the functionfs application you're talking about? And by "completion" do you mean that it completely stops running or is it just sleeping waiting for some input? > The new information is that step (3) consumes a lot of memory and the > theory is the OS is throwing USB user-space code pages out of RAM and > using this RAM for NFS files (root file system is NFS mounted). > > Continuing on with this theory: > After the USB related code pages are no longer in RAM, a USB transaction happens. > Now there is a race condition: > 1) The USB transaction complete interrupt and the OS call into user-space USB related code (functionfs, aio, etc) > 2) The Linux paging system trying to page the user-space USB related code back into RAM > > The theory is that (1) can happen before (2). I'm not sure the inversion of 1 and 2 would cause issues. Swaping out the pages may :-) Let us know if mlockall() helps. -- balbi
Attachment:
signature.asc
Description: PGP signature
