Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!linus!alliant!merk!uvmark!irwin
From: irwin@uvmark.uucp (Frank Irwin)
Newsgroups: comp.unix.aix
Subject: Re: network and 3005
Message-ID: <1991Jun13.223015.70199@uvmark.uucp>
Date: 13 Jun 91 22:30:15 GMT
References: <676362343.53@egsgate.FidoNet.Org>
Organization: Vmark Software, Inc.
Lines: 56

In article <676362343.53@egsgate.FidoNet.Org> Dave.Beedle@f98.n250.z1.FidoNet.Org (Dave Beedle) writes:
>
>>
>>>Recently I have the 3005 upgrade installed(RS6000/320). Since then I got
>>>a lot of trouble with the ethernet. The network crashes 
>>>frequently(about twice a day, unable to rlogin, telnet, etc), 
>>
>>Sounds familiar.  Do the folks in Austin have any comments?  
>>Systems affected are 320 with 16mb/320mb, and 520 with 16mb/600mb.
>>My 530 (64mb/2.5gb) doesn't seem to be affected... is this a hint?
>
>     Add a model 530 with 16meg to the list.  I post about this (or
>something very similar) a couple of weeks ago.  I did talk with software

We had this problem on 3003 and 3005 on our 520 w/32MB.  John Kubiak
of Tech Support finally figured out that it was an mbuf deficiency.

To see if you have the same problem, run the command:

# netstat -m

The results that I got (this was before rebooting the system, which always
cleared things up) was:

912/1024 mbufs in use:
	479 mbufs allocated to data
	77 mbufs allocated to packet headers
	124 mbufs allocated to socket structures
	215 mbufs allocated to protocol control blocks
	2 mbufs allocated to routing table entries
	13 mbufs allocated to socket names and addresses
	2 mbufs allocated to interface addresses
469/469 mapped pages in use
2004 Kbytes allocated to network  (99% in use)
293646 requests for memory denied

The numbers of mbufs in use, mapped pages in use, Kbytes allocated to network,
and requests for memory denied were the clues.

To fix this, I changed the "Maximum Kbytes of real memory allowed for MBUFS"
from 2000 to 4000 using SMIT ("Change/Show Operating System Parameters").

I also had to do the following commands:

# no -o thewall=4000
# chdev -l sys0 -a maxmbuf=4000

The system has been working fine since then, but it would always work for
a couple of weeks after rebooting, and it's only been a couple of days.

If you want to call Tech Support, the problem # is 5859.
-- 
  ===========================================================================
  Frank Irwin                   |  "The game was nothing to write home about,
  Vmark Software, Inc.          |   Unless you were writing home for money."
   ..uunet!merk!uvmark!irwin    |        - Jesse Grant  (thnx Mike)