Date: Wed, 19 May 2004 05:40:11 -0700 (PDT) From: Mark Tinguely <tinguely@casselton.net> To: freebsd-i386@FreeBSD.org Subject: Re: i386/53382: Repetable panics in ffs_vget() on Proliant ML350 with SMP/HTT enabled Message-ID: <200405191240.i4JCeBdl034280@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/53382; it has been noted by GNATS.
From: Mark Tinguely <tinguely@casselton.net>
To: freebsd-gnats-submit@FreeBSD.org, venglin@freebsd.lublin.pl
Cc: tinguely@casselton.net
Subject: Re: i386/53382: Repetable panics in ffs_vget() on Proliant ML350 with SMP/HTT enabled
Date: Wed, 19 May 2004 07:39:19 -0500 (CDT)
another person experienced this problem. He has a tyan dual-xeon mobo with
two CPUs, Adaptec 2100, quality RAM, quality power supply. About every other
night, while under heavy disk I/O, the computer suffered a panic with
tracebacks.
---
MALLOC/malloc/kmem_malloc can still return a NULL pointer if the Kernel
Virtual Memory is depleted or fragmented enough that vm_map_findspace()
fails. I am mostly sending this email for persons searching the bug
database when they encounter the problem, to suggest they increase their
Kernel Virtual Memory in your custom kernel configuration to bypass the
problem:
options KVA_PAGES=XXX
and possibly increase the kmem_map size (default MAX size is 200 MB):
options VM_KMEM_SIZE_MAX="(YYY*1024*1024)"
(or set using the /boot/loader.conf kern.vm.kmem.size setting)
Where the user chooses an appropriate larger value XXX for the KVA.
I suggested a value of 384-512 (1.5-2 GB); and value YYY to increase
the kernel malloc area, maybe to a value of 256.
---
I know changing malloc() to wait for KVM when called with M_WAITOK
has lots of ramifications. But to close this problem report, I would
suggest that if malloc() must return a NULL in the M_WAITOK situation,
FreeBSD should either deny the ffs_vget() request (as the sample patched
below illustrates -- this may happen elsewhere as well) or assert a
panic. Letting the bzero() to page fault on a NULL pointer and panic
indirectly is not the correct thing to do.
---
*** ffs_vfsops.c Sun Jun 23 17:34:52 2002
--- ffs_vfsops.c.fix Fri May 14 09:46:06 2004
***************
*** 1105,1110 ****
--- 1105,1118 ----
MALLOC(ip, struct inode *, sizeof(struct inode),
ump->um_malloctype, M_WAITOK);
+ /*
+ * fail if MALLOC failed.
+ */
+ if (ip == NULL) {
+ printf("ffs_vget: malloc of inode failed\n");
+ return (ENOMEM);
+ }
+
/* Allocate a new vnode/inode. */
error = getnewvnode(VT_UFS, mp, ffs_vnodeop_p, &vp);
if (error) {
---
--Mark Tinguely tinguely@casselton.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405191240.i4JCeBdl034280>