[comp.unix.ultrix] out of mbuf

lawitzke@msudoc.UUCP (John Lawitzke) (10/09/87)

I am runnign Ultrix 1.2 on a VAX 8600 and regularly get 
carshes due to "out of mbuf". It goes down once every one to
two weeks. I realize what the message means. Does any one
know how to prevent it?

zemon@felix.UUCP (Art Zemon) (10/23/87)

Reply-Path:



[The following arrived from an annonymous contributor.  They say that you
simply need a bigger mbuf pool and that this change will give it to
you.  If you only crash every couple of weeks then a value of 512 or
1024 ought to be sufficient.	-- AZ]


To keep the mbuf map from being exhausted you must increase the size
of the map. To do this you must edit 2 files and rebuild your kernel.
To make sure that the old files are not used you must do the following.
cd /sys/$MACHINE_NAME

    make clean	    # does a rm * in your system build dir.

in /sys/h edit mbuf.h you will find the following line. (it's around
line # 55)

    #define	NMBCLUSTERS	256

Change the 256 to either 512, 1024 or 2048, etc.  I recommend 1024.

Then edit /sys/vax/spt.s and you will find the following line ( it's
around line # 99 )

    SYSMAP(Mbmap	,mbutl		,NMBCLUSTERS*CLSIZE)

you MUST change NMBCLUSTERS to what you changed it to in mbuf.h

example

mbuf.h
    #define	NMBCLUSTERS	1024

spt.s
    SYSMAP(Mbmap	,mbutl		,1024*CLSIZE)

bp@pixar.UUCP (The gift to be simple is the gift to be free. - Shaker theme) (11/03/87)

In article <10274@felix.UUCP>, an anonymous contributor wrote...
} ...
} Then edit /sys/vax/spt.s and you will find the following line ( it's
} around line # 99 )
} 
}     SYSMAP(Mbmap	,mbutl		,NMBCLUSTERS*CLSIZE)
} 
} you MUST change NMBCLUSTERS to what you changed it to in mbuf.h
} 
} example
} 
} mbuf.h
}     #define	NMBCLUSTERS	1024
} 
} spt.s
}     SYSMAP(Mbmap	,mbutl		,1024*CLSIZE)

It should not be necessary to edit spt.s unless NMBCLUSTERS is being
defined somewhere else than in mbuf.h . After changing mbuf.h, delete
spt.o and re-make. Caveat - I haven't tested this (I don't buy the fix,
either).

Increasing the number of mbufs is probably a band-aid for the
real problem. Mbufs are being allocated and never freed.
---
Bruce Perens - {sun,ucbvax}!pixar!bp - 415-258-8167

mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (11/05/87)

Reply-Path:


> } Then edit /sys/vax/spt.s and you will find the following line ( it's
> } around line # 99 )
> }     SYSMAP(Mbmap	,mbutl		,NMBCLUSTERS*CLSIZE)
> } you MUST change NMBCLUSTERS to what you changed it to in mbuf.h
> 
> It should not be necessary to edit spt.s unless NMBCLUSTERS is being
> defined somewhere else than in mbuf.h . After changing mbuf.h, delete

You would think so, but for BINARY Ultrix sites, the connection between
mbuf.h and spt.s is sufficiently convoluted that you need to make both
changes as recommended by the "> }" lines.  I don't recall the details
offhand, but spt.s does NOT #include mbuf.h.  It gets NMBCLUSTERS from
some other module that BINARY sites cannot recompile (unless you want to
muck around with adb).

Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

tron@mrecvax.UUCP (Carlos Mendioroz) (11/13/87)

Reply-Path:



In article <11696@felix.UUCP> mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes:
>> } Then edit /sys/vax/spt.s and you will find the following line ( it's
>> } around line # 99 )
>> }     SYSMAP(Mbmap	,mbutl		,NMBCLUSTERS*CLSIZE)
>> } you MUST change NMBCLUSTERS to what you changed it to in mbuf.h
>> 
>> It should not be necessary to edit spt.s unless NMBCLUSTERS is being
>> defined somewhere else than in mbuf.h . After changing mbuf.h, delete
>
>You would think so, but for BINARY Ultrix sites, the connection between
>mbuf.h and spt.s is sufficiently convoluted that you need to make both
>changes as recommended by the "> }" lines.  I don't recall the details
>offhand, but spt.s does NOT #include mbuf.h.  It gets NMBCLUSTERS from
>some other module that BINARY sites cannot recompile (unless you want to
>muck around with adb).
>
>Mike Khaw
>
Well, in ULTRIX 1.2 m, binary distribution, there's a file 
(/usr/sys/BINARY.mvax/assym.s, /usr/sys/SITE/assym.s) that's prepended
to spt.s before compiling. There it is #defined NMBCLUSTERS too.

Anyhow, I think the preprocessor (which interprets #foo commands)
can only read clear files (sources) and symbol tables or any other
data structure from an object are not. 

I don't like (As Bruce) hard linking NMBCLUSTERS to 1024 (or whatever), 
but having it #defined twice is not a good start!

-Carlos Mendioroz <tron@mrecvax.UUCP>
  UUCP: {uunet|pyramid|utai}!atina!mrecvax!tron

P.S.
Thanks Mike, you gave me the clue. Now it works...