Messages in this thread | | | Date | Sun, 25 Apr 2010 12:36:58 -0700 | From | Greg KH <> | Subject | Re: request_firmware API exhaust memory |
| |
On Sun, Apr 25, 2010 at 10:22:54PM +0300, Tomas Winkler wrote: > On Sun, Apr 25, 2010 at 7:37 PM, Greg KH <greg@kroah.com> wrote: > > On Thu, Apr 22, 2010 at 01:22:51AM +0300, Tomas Winkler wrote: > >> On Mon, Apr 19, 2010 at 5:59 PM, Greg KH <greg@kroah.com> wrote: > >> > On Mon, Apr 19, 2010 at 03:20:34PM +0300, Tomas Winkler wrote: > >> >> Lately we've been developing a device that rather more extensively > >> >> used request_firmware API in load and also using pm_notifiers to load > >> >> firmware. > >> > > >> > Do you have a pointer to your driver source anywhere that shows how you > >> > are trying to use the firmware api in this manner? > >> > >> I've attached a very simple ??test driver I'm using. ??Just wanted to > >> eliminate anything else. > >> Bellow is a little script that loads and releases the firmware. My > >> previous observation was wrong. > >> The free memory gradually decreases regardless of number or dangling > >> udevd forks, which are eventually collected if the sleep period is > >> long enough ~10s. > > > > That sounds normal for the free memory. ??Kay, that's also to be expected > > for the udevd forks as well, right? > > Sorry maybe I was not clear what I mean that the memory will be > eventually exhausted and system will crash > Is this normal?
Ah, no, that's not normal. Have you run kmemleak on your module (or test module) to verify that you are properly freeing up the memory?
> Actually I less suspect now udevd as the same happens on android > platform where there is no udev
Which is a sad thing for a whole other range of issues...
thanks,
greg k-h
| |