Date: Sun, 15 Jul 2012 03:31:47 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Bernhard Schmidt <bschmidt@freebsd.org>, freebsd-embedded@freebsd.org, Harm Weites <harm@weites.com> Subject: Re: TP-Link wr1043nd out of swap space Message-ID: <CAJ-Vmo=YTkVsn1eiGPpXewi_48BwDj=A72DwAWsUY_9X7=xC1w@mail.gmail.com> In-Reply-To: <4B538596-937B-46F3-AF8F-17F34BE0C92D@bsdimp.com> References: <1341745590.2740.17.camel@manbearpig.dynamic.weites.net> <201207081805.33574.bschmidt@freebsd.org> <1341841445.2540.10.camel@manbearpig.dynamic.weites.net> <CAOfEmZhPeEiiwUfn=5dt=vnkARV6551r%2BR_pSZrU4=07NiA8ow@mail.gmail.com> <1341849727.2540.11.camel@manbearpig.dynamic.weites.net> <CAOfEmZjLbqD941=wg7ReruhgY4u%2Bu0R7KkeDexFMUVQVssKdCQ@mail.gmail.com> <1342195983.2336.35.camel@manbearpig.dynamic.weites.net> <4B538596-937B-46F3-AF8F-17F34BE0C92D@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I would really appreciate it if people (read; not me) would be able to do the digging needed to get to the bottom of user/kernel memory usage. I really need to focus on just the net80211/wifi stack side of things. I'm going to focus on getting the ath(4) memory usage down over the next few months so it remains feasible to run on 32MB platforms, as those still ship. But I can't keep the rest of the kernel and userland in check. Thanks, Adrian On 13 July 2012 09:45, Warner Losh <imp@bsdimp.com> wrote: > > On Jul 13, 2012, at 10:13 AM, Harm Weites wrote: > >> Hi, >> >> the firmware posted on Adrian's google projects page works ok (which is >> from last December), it even says 10+M free memory. I've flashed my unit >> with a (old) kernel/world from r230847, it leaves ~5M mem available. The >> biggest difference between both is probably my inclusion of gif/pf >> devices, and leaving out the WITNESS/INVARIANTS stuff. Though that >> should probably not make such a huge difference. >> >> I've tried updating my tree to some revisions later, but at r233000 I'm >> left with ~4M available. There are some nice fixes in various places >> after that revision, so I'm eager to get something higher to work. And >> it would be nice to pin-point the cause of the error :) > > It has been my experience that if you want to run general purpose things = on a device, you need at least 8M[*] of ram free after boot with the daemo= ns running. Any less than that, and it becomes very hard to cope with fluc= tuations in load and usage. You'll likely need to go looking for things to= trim, I'm sorry to say. > > Warner > > [*] I've run certain special purpose machines closer to the edge, but the= load on them didn't vary much at all, and they had a very constrained set = of tasks they had to accomplish. And this was back in the 4.x time frame, = and dynamic memory in the kernel is somewhat more vigorous these days. > >> Regards >> >> Marcelo Araujo schreef op vr 13-07-2012 om 10:32 [+0800]: >>> Hello Harm, >>> >>> Did you have any progress to fix your problem, I'm quite interested on >>> it. >>> >>> Best Regards, >>> - Araujo >>> >>> 2012/7/10 Harm Weites <harm@weites.com> >>> Hi, >>> >>> just a typo in my message, not in make.conf :) >>> >>> regards >>> >>> Marcelo Araujo schreef op ma 09-07-2012 om 23:27 [+0800]: >>>> Hello Harm, >>>> >>>> >>>> There is a typo is must be MALLOC_PRODUCTION=3DYES instead of >>> MALLOC >>>> PRODUCION=3DYES. Maybe you could double check! >>>> >>>> >>>> Best Regards, >>>> - Araujo >>>> >>>> 2012/7/9 Harm Weites <harm@weites.com> >>>> Hi Bernard, >>>> >>>> thanks for your suggestion. I've added >>> MALLOC_PRODUCION=3DYES >>>> to /etc/make.conf, and also removed make option >>> DEBUG=3D-g from >>>> the kernel >>>> config. The error still exists though. >>>> >>>> Regards >>>> >>>> Bernhard Schmidt schreef op zo 08-07-2012 om 18:05 >>> [+0200]: >>>>> On Sunday 08 July 2012 13:06:30 Harm Weites wrote: >>>>>> Hi list, >>>>>> >>>>>> After flashing my firmware image on the TP-Link >>> it apears >>>> to run out of >>>>>> swap space when executing /etc/rc, thus halting >>> further >>>> system startup. >>>>>> My mfsroot is actually ~500KB smaller compared >>> to the >>>> result of the >>>>>> standard scripts, and the mount_mfs commands >>> in /etc/rc >>>> are building >>>>>> 512K devices instead of the standard 1M. What >>> could be the >>>> issue here, >>>>>> since there should be even more RAM available >>> compared to >>>> using the >>>>>> image produced by the standard build scripts? >>>>>> >>>>>> Furthermore, I've compiled the kernel without >>> WITNESS, >>>> WITNESS_SKIPSPIN, >>>>>> INVARIANTS and INVARIANT_SUPPORT. >>>>> >>>>> Do you have MALLOC_PRODUCTION defined in your >>> make.conf? If >>>> not, you >>>>> should try to do so. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> freebsd-embedded@freebsd.org mailing list >>>> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>>> To unsubscribe, send any mail to >>>> "freebsd-embedded-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> >>>> -- >>>> Marcelo Araujo >>>> araujo@FreeBSD.org >>>> >>> >>> >>> >>> >>> >>> >>> -- >>> Marcelo Araujo >>> araujo@FreeBSD.org >> >> >> _______________________________________________ >> freebsd-embedded@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.o= rg" > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.or= g"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=YTkVsn1eiGPpXewi_48BwDj=A72DwAWsUY_9X7=xC1w>