Date: Sat, 29 Nov 2008 18:04:25 +0100 From: Lars Engels <lme@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kmem_malloc(16384): kmem_map too small Message-ID: <20081129170425.GN161@e.0x20.net> In-Reply-To: <ggrki4$9iv$1@ger.gmane.org> References: <20081129103534.GM161@e.0x20.net> <ggrki4$9iv$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--gJgGjUUWrnN4mpen Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 29, 2008 at 03:45:06PM +0100, Ivan Voras wrote: > Lars Engels wrote: > > With a ~3 week old current I got the following panic while running qemu: > >=20 > > panic: kmem_malloc(16384): kmem_map too small: 335536128 total allocated >=20 > > #11 0xc05d5b16 in panic (fmt=3D0xc090980a "kmem_malloc(%ld): kmem_map t= oo small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:559 > > #12 0xc0802f9a in kmem_malloc (map=3D0xc1490084, size=3D16384, flags=3D= 1026) at /usr/src/sys/vm/vm_kern.c:303 > > #13 0xc07f9c37 in page_alloc (zone=3D0x0, bytes=3D16384, pflag=3D0xe53a= 09d7 "\002", wait=3D1026) at /usr/src/sys/vm/uma_core.c:952 > > #14 0xc07fc720 in uma_large_malloc (size=3D16384, wait=3D1026) at /usr/= src/sys/vm/uma_core.c:2706 > > #15 0xc05c4d08 in malloc (size=3D16384, mtp=3D0xc0955f40, flags=3D1026)= at /usr/src/sys/kern/kern_malloc.c:393 > > #16 0xc07db265 in softdep_disk_io_initiation (bp=3D0xd8228210) at /usr/= src/sys/ufs/ffs/ffs_softdep.c:3815 > > #17 0xc07dfebc in ffs_geom_strategy (bo=3D0xc461a3cc, bp=3D0xd8228210) = at buf.h:404 > > #18 0xc07efdd3 in ufs_strategy (ap=3D0xe53a0b90) at /usr/src/sys/ufs/uf= s/ufs_vnops.c:2027 > > #19 0xc088f12d in VOP_STRATEGY_APV (vop=3D0xc0957320, a=3D0xe53a0b90) a= t vnode_if.c:1771 > > #20 0xc063f50e in bufstrategy (bo=3D0xc6259b20, bp=3D0xd8228210) at vno= de_if.h:920 > > #21 0xc06456e1 in bufwrite (bp=3D0xd8228210) at buf.h:397 > > #22 0xc063ea48 in bawrite (bp=3D0xd8228210) at buf.h:385 > > #23 0xc07e4d6c in ffs_syncvnode (vp=3D0xc6259a78, waitfor=3D1) at /usr/= src/sys/ufs/ffs/ffs_vnops.c:264 > > #24 0xc07e4f7c in ffs_fsync (ap=3D0xe53a0c5c) at /usr/src/sys/ufs/ffs/f= fs_vnops.c:185 > > #25 0xc088e312 in VOP_FSYNC_APV (vop=3D0xc0956e00, a=3D0xe53a0c5c) at v= node_if.c:1007 > > #26 0xc0662aa9 in fsync (td=3D0xc46a28c0, uap=3D0xe53a0cf8) at vnode_if= =2Eh:529 > > #27 0xc0881555 in syscall (frame=3D0xe53a0d38) at /usr/src/sys/i386/i38= 6/trap.c:1076 > > #28 0xc0866d60 in Xint0x80_syscall () at /usr/src/sys/i386/i386/excepti= on.s:261 > > #29 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > >=20 > > # uname -a > > FreeBSD maggie.bsd-geek.de 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Tue Nov = 4 22:52:12 CET 2008 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/MAGGI= E i386 >=20 > It looks like qemu for some reason causes your system to allocate a lot > of memory for kernel's internal operation (either that or there's a > memory leak somewhere). You should increase kmem_size just as you would > do for the same situation with ZFS (see > http://wiki.freebsd.org/ZFSTuningGuide). >=20 > Just for information: do you use kqemu? Thanks, I set kmem_size to 512M now and will tell if the panic happens again. Yes, I use kqemu: kqemu-kmod-1.3.0.p11_9 --gJgGjUUWrnN4mpen Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkxdhkACgkQKc512sD3afhjAwCcDbMi+nqlU6PiSRWFpsIxV4Bv ZAUAnRd2wEtMzcaRBzpzc6KLeZsTLfMG =hfxv -----END PGP SIGNATURE----- --gJgGjUUWrnN4mpen--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081129170425.GN161>