On Sun, 13 Jun 2004, Gleb Smirnoff wrote: > Today we have evidenced a panic on a DELL PowerEdge 1400 with two > processors on board: > > panic: kmem_malloc(4096): kmem_map too small: 209715200 total allocated > cpuid = 0; > > I have dump saved, so I'll be glad to feed anyone with information to > help fix this issue. Just to confirm -- what date -CURRENT are you using? As you probably saw on the list, there have been a couple of memory leaks and other resource leaks introduced and then fixed in the past two weeks as changes were made to network memory allocation and locking. It's not impossible to imagine this is the result of one of those leaks, assuming it's from the date range affected by the leaks, so we should rule that out up front... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Senior Research Scientist, McAfee Research > > backtrace: > (kgdb) bt > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:236 > #1 0xc0446a05 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xdbd1a67c "") > at /usr/src/sys/ddb/db_command.c:551 > #2 0xc0446752 in db_command (last_cmdp=0xc06a3ea0, cmd_table=0x0, > aux_cmd_tablep=0xc0674b88, aux_cmd_tablep_end=0xc0674b8c) > at /usr/src/sys/ddb/db_command.c:348 > #3 0xc0446895 in db_command_loop () at /usr/src/sys/ddb/db_command.c:475 > #4 0xc04499f5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73 > #5 0xc060e8cc in kdb_trap (type=3, code=0, regs=0xdbd1a7d0) > at /usr/src/sys/i386/i386/db_interface.c:159 > #6 0xc0623e28 in trap (frame= > {tf_fs = -1068498920, tf_es = -1067057136, tf_ds = -1067122672, tf_edi = -1067022542, tf_esi = 1, tf_ebp = -607016932, tf_isp = -607016964, tf_ebx = 0, tf_edx = 0, tf_ecx = -1061076992, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067389995, tf_cs = 8, tf_eflags = 658, tf_esp = -1067002619, tf_ss = -1067087802}) > at /usr/src/sys/i386/i386/trap.c:579 > #7 0xc060ebd5 in Debugger (msg=0x0) at machine/cpufunc.h:56 > #8 0xc04e34b6 in panic ( > fmt=0xc0668732 "kmem_malloc(%ld): kmem_map too small: %ld total allocated") > at /usr/src/sys/kern/kern_shutdown.c:532 > #9 0xc05d2cbb in kmem_malloc (map=0xc0c3a0a0, size=4096, flags=258) > at /usr/src/sys/vm/vm_kern.c:324 > #10 0xc05e4367 in page_alloc (zone=0xc1ee9580, bytes=0, pflag=0x0, wait=0) > at /usr/src/sys/vm/uma_core.c:892 > #11 0xc05e3ffd in slab_zalloc (zone=0xc1ee9580, wait=258) > at /usr/src/sys/vm/uma_core.c:789 > #12 0xc05e570a in uma_zone_slab (zone=0xc1ee9580, flags=2) > at /usr/src/sys/vm/uma_core.c:1772 > #13 0xc05e594f in uma_zalloc_bucket (zone=0xc1ee9580, flags=2) > at /usr/src/sys/vm/uma_core.c:1875 > #14 0xc05e55ad in uma_zalloc_arg (zone=0xc1ee9580, udata=0x0, flags=2) > at /usr/src/sys/vm/uma_core.c:1699 > #15 0xc05bae4c in ffs_vget (mp=0xc1dfcc00, ino=3111815, flags=2, vpp=0xdbd1aa4c) > at /usr/src/sys/vm/uma.h:270 > #16 0xc05c2bb2 in ufs_lookup (ap=0xdbd1ab10) at /usr/src/sys/ufs/ufs/ufs_lookup.c:599 > #17 0xc05c9d98 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819 > #18 0xc0535191 in vfs_cache_lookup (ap=0x0) at vnode_if.h:82 > #19 0xc05c9d98 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819 > #20 0xc053a292 in lookup (ndp=0xdbd1ac28) at vnode_if.h:52 > #21 0xc0539c7e in namei (ndp=0xdbd1ac28) at /usr/src/sys/kern/vfs_lookup.c:179 > #22 0xc0546bd2 in lstat (td=0xc1d08840, uap=0xdbd1ad14) > at /usr/src/sys/kern/vfs_syscalls.c:2059 > #23 0xc06247b0 in syscall (frame= > {tf_fs = 134545455, tf_es = 134545455, tf_ds = -1078001617, tf_edi = 134570496, tf_esi = 134570568, tf_ebp = -1077941080, tf_isp = -607015564, tf_ebx = 672438156, tf_edx = 134561792, tf_ecx = 134561792, tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 671910239, tf_cs = 31, tf_eflags = 582, tf_esp = -1077941236, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1004 > #24 0x280c895f in ?? () > ---Can't read userspace from dump, or kernel process--- > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Sun Jun 13 2004 - 14:03:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC