[Backtrace] 4.9 and 5.1-RELEASE occasionly panic on RAM > 4GB without PAE (long)

[=?gb2312?B?WGluIExJL8Du9s4=?=]

=20

> -----Original Message-----
> From: Doug White [mailto:dwhite at gumbysoft.com]=20
> Sent: Thursday, December 18, 2003 8:58 AM
> To: Xin LI/=C0=EE=F6=CE
> Cc: stable at FreeBSD.org; current at freebsd.org
> Subject: Re: [Backtrace] 4.9 and 5.1-RELEASE occasionly panic=20
> on RAM > 4GB without PAE (long)
>=20
> PAE only has effect for >4GB (strictly), so exactly 4GB will=20
> work fine with !PAE.
Oh... I am aware of this issue, however, only machines have RAM > 4GB =
expose
the problem. So I suspect that something has triggered the problem in =
4GB
w/o PAE case. Because the system will not even boot into single user =
mode
under a PAE configuration, I was unable to provide any useful =
information
about the PAE case.

I guess that there is some race condition inside the vm or pmap code.
However, after a preliminary research on these code I did not found =
problem.

> Its probably due to poor tuning in this case.  See the=20
> tuning(7) man page and innumerable mailing lists posts. =20
> Basically, you want to turn down maxusers (128 or so works=20
> best) and maybe change the kernel/user boundary and kmem=20
> sizes.  vmstat -m is useful to keep track of kernel memory use.
When we have removed some RAM, in other words, install 2GB memory on the
box, the panic's goes away. Please note that the problem is not due to
defective RAM chips as we have tested all possible combinations and the
problem persists.

>=20
> Also forkbombs (which is what your program is, effectively)=20
> are best controlled by using user resource limits.  They're=20
> there for a reason. See the login.conf(5) man page.
Oh... I think this is important, however, I got no reason why a server
running ordinary service will cause panic when heavy load.

Implementing a forkbomb is a Bad Idea(tm), but I will still argue that =
our
daily run and crashdumps shows that this panic is mostly fork-and-malloc
related, so we have the test program, and it triggered similar panic as =
we
have. Because that our panic could not be easily to reproduce, and the =
two
panic's were so similiar, I think they might be the same problem.

In addition, IMHO, a userland program should never cause a kernel-panic =
if
the kernel is implemented very well without any flaw. As I mentioned in =
last
letter, on a configuration having 2GB of RAM, the system seemed to be
rock-solid. That's why I have the ugly proof code...

> > panic: pmap_new_proc: u_map allocation failed
>=20
> kmem exhaustion condition in -stable.
Er... Is this problem only -STABLE related? Thanks!

Xin LI