home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / ultrix / 8494 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  3.1 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!uvaarpa!concert!borg!trantor!white
  2. From: white@trantor.cs.unc.edu (Brian T. White)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: fix for 'cant get mbufs' problem
  5. Message-ID: <17837@borg.cs.unc.edu>
  6. Date: 23 Nov 92 17:22:57 GMT
  7. Sender: news@cs.unc.edu
  8. Lines: 67
  9.  
  10. We were recently experiencing problems with a DECsystem 5000/240
  11. hanging after producing a long string of 'cant get mbufs' messages.
  12. The machine, which has 25 clients and about 5.2 GB of disk space,
  13. was crashing roughly daily, but since the fix it has been up two
  14. weeks with no problem.
  15.  
  16. Our DEC technical rep, to whom we are eternally grateful, dug 
  17. through some mail messages and found the following suggestion, which 
  18. worked:
  19.  
  20. ****************************************************************
  21. "cant get mbufs" means you ran out of km_alloc map space, or you
  22. ran short of physical memory (temporarily) and thus, dropped an
  23. input packet.
  24.  
  25. You probably need to increase the km_alloc map on the system
  26. experiencing the problem.   Adjust the value of KMEMUMAP in the
  27. sys/machine/vax/vmparam.h file.  [we modified sys/machine/mips/vmparam.h]
  28.  
  29. Background:
  30.  
  31. The message "cant get mbufs" is printed to the console by the kernel
  32. when a call to kmalloc has failed.  A kmalloc call can fail if there are
  33. not enough pte's [process table entries] available to map a given region
  34. of memory, or it can fail if there are pte's available but the physical
  35. memory is lacking at that particular instant.  A number of calls to the
  36. kmalloc kernel routing specify that the call is to wait for resources to
  37. become available should there be a temporary shortage.  The call in
  38. question, which results in the "cant get mbufs" message does not specify
  39. that a wait should take place.  Thus, the kmalloc routine returns
  40. immediately with an error message, the kernel prints a message
  41. indicating the unavailability of resources, and the network packet is
  42. discarded.
  43.  
  44. This most likely occurs during a network "spike" whereby a host is
  45. flooded with hundreds of incoming packets during a brief instant, and it
  46. is unable to process all of the packets.
  47.  
  48. If this happens only randomly and without much frequency, you can ignore
  49. it.  If the machine hangs or locks up following the message, or if you
  50. see this message often, you should increases the value of KMEMUMAP.
  51. ****************************************************************
  52.  
  53. Note:  KMEMUMAP is dependant on the value of PHYSMEM, which is set to 32 on
  54. our servers.  The code in the vmparam.h file that specifies KMEMUMAP
  55. is as follows:
  56.  
  57. #if (PHYSMEM/10 < LOW_WATER)
  58. #define KMEMUMAP (LOW_WATER*256+KMEMSLOP)
  59. #else
  60. #if (PHYSMEM/10 > HIGH_WATER)
  61. #define KMEMUMAP (HIGH_WATER*256+KMEMSLOP)
  62. #else
  63. #define KMEMUMAP (PHYSMEM/10*256+KMEMSLOP)
  64. #endif
  65. #endif
  66.  
  67. I changed it to be just the following:
  68.  
  69. #define KMEMUMAP (HIGH_WATER*256+KMEMSLOP)
  70.  
  71.  
  72. Our machine has 32 MB, and the physmem variable is set to 32, which 
  73. seems intuitively correct.  There have been suggestions that raising
  74. physical memory or the value of the physmem variable would fix the
  75. problem, but it would appear that those solutions owe their success
  76. to the dependence of KMEMUMAP on PHYSMEM.  
  77.