home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8653 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.9 KB  |  89 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!cs.utexas.edu!sun-barr!decwrl!csus.edu!netcom.com!alm
  3. From: alm@netcom.com (Andrew Moore)
  4. Subject: Re: NFS problems with 386bsd (pl58+)
  5. Message-ID: <1992Nov9.233604.4360@netcom.com>
  6. Keywords: NFS 386BSD SVR4
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <1992Nov9.193850.14331@lgc.com>
  9. Date: Mon, 9 Nov 1992 23:36:04 GMT
  10. Lines: 77
  11.  
  12. In article <1992Nov9.193850.14331@lgc.com> danson@lgc.com (Doug Anson) writes:
  13. >Hi:
  14. >
  15. >I have a small two node network where one machine is running 386bsd and the
  16. >other is running SVR4.0.3.6. I have been NFS mounting a partition from the
  17. >386bsd machine to the SVR4.0.3.6 machine. With this mount, I have tried compiling a large application (i.e. gcc.2.3.1) for use in the SVR4 environment.
  18. >However, I have run into what looks like a memory leak in 386bsd within the
  19. >NFS (or wd8003) subsystem. 
  20. >
  21. >Basically, what happens is that the NFS mount works fine when the NFS traffic
  22. >is fairly light. However, during heavy NFS I/O, I'll sometimes panic the
  23. >386bsd kernel. The panic complains:
  24. >                          kmem_malloc: kmem_map too small
  25. >
  26.  
  27. This may help... (another posting to 4bsd.bugs included a patch which
  28. doesn't apply to 386BSD).
  29. -AM
  30.  
  31. From: julian@tfs.com (Julian Elischer)
  32. Subject: IMPORTANT PATCH!
  33. Message-ID: <1992Nov3.071934.25466@tfs.com>
  34. Organization: Trw Financial Systems
  35. Date: Tue, 3 Nov 1992 07:19:34 GMT
  36. Lines: 49
  37.  
  38.  
  39. The following patch fixes a randomly initialised variable in the icmp
  40. and raw socket code that can cause 'ping' and 'traceroute'
  41. to never fully close their socket's internal structures
  42. leading to a geometrically increasing number of lost mbufs until
  43. the system runs out of appropriate virtual space, at which
  44. time the system panics with a 'kmem_alloc: map too small' 
  45. and halts.
  46.  
  47. EVERY time you run ping and traceroute you make the problem
  48. worse
  49. The 'rights' entry should not be there.
  50.  
  51. julian
  52. +----------------------------------+       ______ _  __
  53. |   __--_|\  Julian Elischer       |       \     U \/ / On assignment
  54. |  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
  55. | (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
  56. +- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\
  57.       v
  58.  
  59.  
  60.  
  61.  
  62. *** netinet/raw_ip.c.orig    Mon Nov  2 23:09:51 1992
  63. --- netinet/raw_ip.c    Mon Nov  2 23:10:30 1992
  64. ***************
  65. *** 189,198 ****
  66.   }
  67.   
  68.   /*ARGSUSED*/
  69. ! rip_usrreq(so, req, m, nam, rights, control)
  70.       register struct socket *so;
  71.       int req;
  72. !     struct mbuf *m, *nam, *rights, *control;
  73.   {
  74.       register int error = 0;
  75.       register struct raw_inpcb *rp = sotorawinpcb(so);
  76. --- 189,198 ----
  77.   }
  78.   
  79.   /*ARGSUSED*/
  80. ! rip_usrreq(so, req, m, nam, control)
  81.       register struct socket *so;
  82.       int req;
  83. !     struct mbuf *m, *nam, *control;
  84.   {
  85.       register int error = 0;
  86.       register struct raw_inpcb *rp = sotorawinpcb(so);
  87.  
  88.  
  89.