home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / networks / tcpip / multinet / 2087 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  3.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!network.ucsd.edu!mvb.saic.com!tgv.com!info-multinet
  2. From: adelman@TGV.COM
  3. Newsgroups: vmsnet.networks.tcp-ip.multinet
  4. Subject: Re: No buffer space errors
  5. Message-ID: <246025DE02SEP92231714@TGV.COM>
  6. Date: 2 Sep 92 23:17:14 GMT
  7. Organization: The INFO-MULTINET Community
  8. Lines: 61
  9. X-Gateway-Source-Info: INTERNET
  10. X-Return-path: <info-multinet-relay@TGV.COM>
  11. X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
  12. Nntp-Posting-Host: Mvb.Saic.Com
  13.  
  14. >   Yesterday, we had several strange problems that occured with one of our
  15. >  systems running Multinet.  Multinet usually runs solid as a rock, but it
  16. >  seemed to be really hosed up and nothing we could do short of a reboot
  17. >  could fix it.
  18.  
  19. >  Our system is a VAX 6420 running VMS 5.5 and we run Multinet 3.0. (We also
  20. >  have Multinet 3.0 running under VMS 5.5 on another cluster which contains
  21. >  a 6420 and a 6640 and both of these systems were functioning fine at the
  22. >  time.)  Yesterday we noticed that when users tried to telnet or rsh to our
  23. >  system from other local systems in the same building, they received an error
  24. >  message (text varies depending on where & what they were coming from)
  25. >  indicating the system was not responding. The system was up however, it
  26. >  hadn't been rebooted in 30+ days.  When we tried to telnet from our system to
  27. >  anywhere else, we got the message:
  28.  
  29. >   %MULTINET-W-ENOBUFS, No buffer space available
  30.  
  31. >  We also got a number of variations on the above message on our OPCOM
  32. >  throughout the day:
  33. > -------------------------------------------------------------------------------
  34. > MultiNet Server: R_SERVICES: I/O error %MULTINET-W-ENOBUFS, No buffer space
  35. >  available
  36. > MultiNet Server: R_SERVICES: Socket write error %MULTINET-W-ENOBUFS, No buffer
  37. >  space available
  38. > MultiNet Server: R_SERVICES: getpeername: %MULTINET-W-ENOBUFS, No buffer space
  39. >  available
  40. > MultiNet Server: Standard_Connected setsockopt KEEPALIVE: No buffer space
  41. >  available
  42. > MultiNet Server: accept: No buffer space available
  43. > MultiNet Server: FTP: setsockopt (SO_KEEPALIVE): %MULTINET-W-ENOBUFS, No buffer
  44. >  space available
  45. > MultiNet Server: FTP: I/O error %MULTINET-W-ENOBUFS, No buffer space available
  46. > -------------------------------------------------------------------------------
  47.  
  48. >  These problems were intermittent - they would appear then disappear.  We
  49. >  tried restarting the multinet server from the config/servers utility, and
  50. >  killing the MULTINET_SERVER process and rerunning the START_MULTINET.COM
  51. >  procedure, but after a while problems would return.    It took a reboot to
  52. >  clean things up, and we haven't seen the problem since.
  53.  
  54. >  Does anyone have any ideas what we need to tune to keep from doing a reboot
  55. >  if this happens again?
  56.  
  57.     Next time it is happening open a support call with us at 408-427-4366
  58. or SERVICE@TGV.COM. Also, we recommend you upgrade to MultiNet V3.1;
  59. V3.0 is no longer supported.
  60.  
  61.     The first thing we'll need is to see the output from a MULTINET SHOW/BUF
  62. command to see if it has logged any "requests for memory denied".
  63.  
  64.     If it HAS, then the problem is either too low a value of SPTREQ or that
  65. you're machine is so busy that the default buffering is not enough (a very
  66. rare case, in which we'll give you a patch to raise it).
  67.  
  68.     If it HAS NOT, then the problem is most likely a wedged Ethernet
  69. controller which is refusing to transmit packets.
  70.  
  71.     In either case, we need to see the problem while it is happening.
  72.  
  73.                                 Ken
  74.  
  75.