> 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? "device app runs to completion" means an executable on the embedded device starts, downloads a 70 Mbyte file from the PC to the device, then exits. It is not waiting for input. This device app, when running, consumes much memory and some of that memory is associated with root file system files mounted over NFS. A colleague claims mlockall() does not help, and says it is not a good idea anyway. I am afraid I have screwed up big time by using functionfs and am feeling pressure to move things into the Linux kernel. Andy Purcell > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi@xxxxxxxxxxxxxxx] > Sent: Wednesday, November 1, 2017 4:44 AM > To: PURCELL,ANDY (K-Loveland,ex1) <andy_purcell@xxxxxxxxxxxx>; linux- > usb@xxxxxxxxxxxxxxx > Subject: RE: Linux and usb device drivers using functionfs > > > 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 -- 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
