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...