Re: HEADS UP: New ZFS in the tree.

From: Nikolay Denev <ndenev_at_gmail.com>
Date: Mon, 24 Nov 2008 13:23:23 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 24 Nov, 2008, at 12:31 , Nikolay Denev wrote:
>
> With absolutely nothing in loader.conf and these defaults :
>
> vfs.zfs.arc_max: 863907840
> vm.kmem_size: 1382252544
> vm.kmem_size_max: 4509713203
>
> I got spontaneous reboot in only after 20-30 minutes of bonnie++
>
> - --
> Regards,
> Nikolay Denev
>
>

Here is the backtrace from the crashdump :

Dump header from device /dev/da0s1b
   Architecture: amd64
   Architecture Version: 2
   Dump Length: 1685811200B (1607 MB)
   Blocksize: 512
   Dumptime: Mon Nov 24 12:52:42 2008
   Hostname: postserver.example.com
   Magic: FreeBSD Kernel Dump
   Version String: FreeBSD 8.0-CURRENT #1: Tue Nov 18 17:43:53 UTC 2008
     ndenev_at_postserver.example.com:/usr/obj/usr/src/sys/CORE
   Panic String: kmem_malloc(90112): kmem_map too small: 1366536192  
total allocated
   Dump Parity: 4023666266
   Bounds: 0
   Dump Status: good

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xffffffff802e81bf in boot (howto=260) at /usr/src/sys/kern/ 
kern_shutdown.c:420
#2  0xffffffff802e8634 in panic (fmt=0xffffffff804a2638  
"kmem_malloc(%ld): kmem_map too small: %ld total allocated")
     at /usr/src/sys/kern/kern_shutdown.c:576
#3  0xffffffff803fa15e in kmem_malloc (map=0xffffff00010000d8,  
size=90112, flags=2) at /usr/src/sys/vm/vm_kern.c:303
#4  0xffffffff803f4306 in uma_large_malloc (size=90112, wait=2) at / 
usr/src/sys/vm/uma_core.c:2706
#5  0xffffffff802d8d22 in malloc (size=90112, mtp=0xffffffff808fe4e0,  
flags=2) at /usr/src/sys/kern/kern_malloc.c:393
#6  0xffffffff80875576 in vdev_queue_io_to_issue  
(vq=0xffffff000468dc20, pending_limit=Variable "pending_limit" is not  
available.
)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ 
common/fs/zfs/vdev_queue.c:227
#7  0xffffffff808756ec in vdev_queue_io_done (zio=0xffffff00518fa5a0)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ 
common/fs/zfs/vdev_queue.c:313
#8  0xffffffff80886c20 in zio_vdev_io_done (zio=0xffffff00518fa5a0)  
at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/ 
fs/zfs/zio.c:1845
#9  0xffffffff808852c0 in zio_execute (zio=0xffffff00518fa5a0) at /usr/ 
src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/ 
zio.c:996
#10 0xffffffff8082df6c in taskq_thread (arg=Variable "arg" is not  
available.
) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ 
common/os/taskq.c:854
#11 0xffffffff802c9b7d in fork_exit (callout=0xffffffff8082dd98  
<taskq_thread>, arg=0xffffff00047f0b40, frame=0xfffffffeb987dc90)
     at /usr/src/sys/kern/kern_fork.c:815
#12 0xffffffff8041333e in fork_trampoline () at /usr/src/sys/amd64/ 
amd64/exception.S:521
#13 0x0000000000000000 in ?? ()
#14 0x0000000000000000 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x0000000000000000 in ?? ()
#17 0x0000000000000000 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x00000000007bc000 in ?? ()
#38 0x000000000000000b in ?? ()
#39 0xffffffff8063a400 in affinity ()
#40 0xffffffff8063a400 in affinity ()
#41 0xffffff0004c6c720 in ?? ()
#42 0xfffffffeb987d2e0 in ?? ()
#43 0xfffffffeb987d298 in ?? ()
#44 0xffffff0001498ab0 in ?? ()
#45 0xffffffff8030959b in sched_switch (td=0xffffffff8082dd98,  
newtd=0xffffff00047f0b40, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1848
Previous frame inner to this frame (corrupt stack?)

Isn't kmem_size supposed to automaticaly grow up-to kmem_size_max ?


- --
Regards,
Nikolay Denev




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAkkqjqsACgkQHNAJ/fLbfrkqTQCaA3dZXMdvIt8aLAyVOKrlgjUW
tqUAn2L80ZogYh0NoUI4SElySiN9qWKB
=1D6v
-----END PGP SIGNATURE-----
Received on Mon Nov 24 2008 - 10:23:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC