Date: Thu, 22 Aug 2002 02:55:15 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mark Santcroos <marks@ripe.net> Cc: Martin Blapp <mb@imp.ch>, Soeren Schmidt <sos@freebsd.dk>, Don Lewis <dl-freebsd@catspoiler.org>, ktsin@acm.org, freebsd-current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Memory corruption in CURRENT Message-ID: <3D64B503.EC6D664D@mindspring.com> References: <20020822111650.I45839-100000@levais.imp.ch> <3D64B111.A57FFB31@mindspring.com> <20020822094104.GA17100@ripe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Santcroos wrote: > On Thu, Aug 22, 2002 at 02:38:25AM -0700, Terry Lambert wrote: > > Alternatively, rather than those options, try losing 512M of > > the RAM... I note they are all 1G boxes. > > No, mine is 256MB. Correction: all of his were 1G, and should be halved. *You*, on the other hand, should try doubling the RAM size. 8-). Another potential winner is: options maxfiles=50000 Note that I believe this one, the RAM size change, and the compile without debug all merely mask, rather than fixing, the problem (i.e. it's not the code that's generated, it's a side effect of a more subtle and amusing problem). I don't believe anyone actually loads kernels with debug symbols anyway if you "config -g GENERIC", unless you intentionally copy up "kernel.debug", you will get the stripped one). The suggested options, if they work, actually *fix* the problem, but it's a really pessimal way to go about it (they work by making the requisite preconditions impossible to trigger); only an idiot would run with those options, unless they had no other choice in the matter (e.g. they had local kernel hacks that broke all of the other workarounds, with no hope of repair). If it's what I think it is, it's more fixable than that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D64B503.EC6D664D>