Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 May 1996 05:18:15 -0700
From:      David Greenman <davidg@Root.COM>
To:        brian@MediaCity.com
Cc:        msmith@atrad.adelaide.edu.au (Michael Smith), randy@zyzzyva.com, et-users@netrail.net, freebsd-isp@FreeBSD.ORG, stable@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: Continued MBUF problem with ET V.35 card 
Message-ID:  <199605091218.FAA02021@Root.COM>
In-Reply-To: Your message of "Thu, 09 May 1996 01:28:40 PDT." <199605090828.BAA14028@MediaCity.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>Michael Smith wrote:
>> Randy Terbush stands accused of saying:
>> > 
>> > As some of you may remember, I reported a problem with MBUF leakage
>> > on a FreeBSD-stable system running an Emerging Technologies ET5025
>> > card. After Dennis' indication that the problem was FreeBSD-stable
>> > and rather strong suggestion that I need to be running 2.1.0, I 
>> > have reinstalled this system running stock FreeBSD-2.1.0. The
>> > problem still exists and can be directly related to activity over
>> > the 56K connection. A much busier system of same kernel vintage
>> > without the ET drivers hovers at around '75 mbufs in use' after
>> > several days of uptime.  The system will reach it's max of 4096K
>> > after about 48 hours of uptime and eventually reboot. I'm at a loss
>> > for how to track this down and would heartily welcome more 
>> > productive suggestions.
>> 
>> Hit Dennis on the head and get him to admit that it's his drivers 8)
>
>Some months ago, I worked with Dennis to track down the mbuf leak
>problem.  The leak was in FreeBSD code, not his driver.

   Yes, and for the record this was caused by a small change to the MGET/MFREE
macros. We used to have a private pool of mbufs to optimize performance, but
this was found to conflict with the allocation-type tracking in malloc() and
lead to system instabilities. By reverting the macros back to their originals,
the code in Dennis's driver that allocated and freed mbufs was still sticking
them in this private pool - one the rest of the system didn't know about, and
thus the "leak".
   There have been no changes to the mbuf allocation code since then.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605091218.FAA02021>