Robert Watson wrote: > It would be extremely helpful if you could figure out where in the kernel > 0xc04cbf38 is. You should be able to do this using a kernel on disk; > debugging, etc, is not necessary. If possible, DDB stack traces or the > results of gdb on a dump would also be extremely helpful. I get a very similar stack track traversing through sossend(), under heavy NFS load on a 1GB machine. Note the panic message here, and the peculiarity that previous incarnations of -current did not panic under similar load. It is highly reproduceable via a 'make installworld' via NFS with /usr/src and /usr/obj mounted. The NFS serving machine will always panic using vanilla GENERIC: [root_at_pippin root]$ panic: kmem_malloc(4096): kmem_map too small: 40894464 total allocated cpuid = 0; Debugger("panic") Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db> where Debugger(c0882cc9,0,c089a26c,cc191aac,100) at Debugger+0x55 panic(c089a26c,1000,2700000,cc191ad8,c0955520) at panic+0x156 kmem_malloc(c103a0a0,1000,102,cc191b2c,c07d562d) at kmem_malloc+0xab page_alloc(c1021b00,1000,cc191b1f,102,c0971c48) at page_alloc+0x27 slab_zalloc(c1021b00,2,8,c089bbdf,736) at slab_zalloc+0xad uma_zone_slab(c1021b00,2,c089bbdf,736,80) at uma_zone_slab+0xea uma_zalloc_bucket(c1021b00,2,c089bbdf,699,c1651c38) at uma_zalloc_bucket+0x15f uma_zalloc_arg(c1021b00,cc191be0,2,c08820b7,116) at uma_zalloc_arg+0x2fd sosend(c15f8988,0,cc191c4c,0,0) at sosend+0x356 kern_sendit(c14eec60,3,cc191cc4,0,0) at kern_sendit+0x19c sendit(c14eec60,3,cc191cc4,0,bfbfe410) at sendit+0x16e sendto(c14eec60,cc191d14,18,434,6) at sendto+0x5b syscall(2f,2f,2f,bfbfe410,44) at syscall+0x2a0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c89df, esp = 0xbfbfdf4c, eb p = 0xbfbfdf78 --- Now this is with a dump that occured earlier than the above ddb session, but same stack trace.. here's the sossend() info. let me know what you want to see. I also have a stack trace referencing the NFS kernel bits that's slightly different. #cat info.3 Good dump found on device /dev/ad0s1b Architecture: i386 Architecture version: 1 Dump length: 134201344B (127 MB) Blocksize: 512 Dumptime: Thu Jun 10 15:02:35 2004 Hostname: pippin Versionstring: FreeBSD 5.2-CURRENT #6: Thu Jun 10 12:50:49 PDT 2004 root_at_pippin:/usr/obj/usr/src/sys/GENERIC Panicstring: kmem_malloc(4096): kmem_map too small: 40894464 total allocated Bounds: 3 (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file kernel (kgdb) core-file /var/crash/vmcore.3 panic: kmem_malloc(4096): kmem_map too small: 40894464 total allocated panic messages: --- panic: kmem_malloc(4096): kmem_map too small: 40894464 total allocated cpuid = 0; Debugger("panic") panic: from debugger cpuid = 0; Uptime: 32m33s Dumping 127 MB 16 32 48 64 80 96 112 --- Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:236 236 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:236 #1 0xc064ffd9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:370 #2 0xc06503dd in panic () at /usr/src/sys/kern/kern_shutdown.c:548 #3 0xc0469902 in db_panic () at /usr/src/sys/ddb/db_command.c:453 #4 0xc0469862 in db_command (last_cmdp=0xc09250a0, cmd_table=0x0, aux_cmd_tablep=0xc08a6f00, aux_cmd_tablep_end=0xc08a6f18) at /usr/src/sys/ddb/db_command.c:348 #5 0xc04699a5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:475 #6 0xc046cb05 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73 #7 0xc080132c in kdb_trap (type=3, code=0, regs=0xcc155a28) at /usr/src/sys/i386/i386/db_interface.c:159 #8 0xc0817948 in trap (frame= {tf_fs = -1066991592, tf_es = -1064763376, tf_ds = -1064828912, tf_edi = - 1064721812, tf_esi = 1, tf_ebp = -871015820, tf_isp = -871015852, tf_ebx = 0, tf _edx = 0, tf_ecx = -1056882688, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1065347531, tf_cs = 8, tf_eflags = 658, tf_esp = -1064702569, tf_ss = -1064817 463}) at /usr/src/sys/i386/i386/trap.c:579 #9 0xc0801635 in Debugger (msg=0x0) at machine/cpufunc.h:56 #10 0xc0650376 in panic ( fmt=0xc089a26c "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:532 #11 0xc07c43cb in kmem_malloc (map=0xc103a0a0, size=4096, flags=258) at /usr/src/sys/vm/vm_kern.c:324 #12 0xc07d59a7 in page_alloc (zone=0xc1021b00, bytes=0, pflag=0x0, wait=0) at /usr/src/sys/vm/uma_core.c:892 #13 0xc07d562d in slab_zalloc (zone=0xc1021b00, wait=258) at /usr/src/sys/vm/uma_core.c:789 #14 0xc07d6d4a in uma_zone_slab (zone=0xc1021b00, flags=2) at /usr/src/sys/vm/uma_core.c:1772 #15 0xc07d70a1 in uma_zalloc_internal (zone=0xc1021b00, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1936 #16 0xc07d6c52 in uma_zalloc_arg (zone=0xc1021b00, udata=0xcc155be0, flags=2) at /usr/src/sys/vm/uma_core.c:1711 #17 0xc0690356 in sosend (so=0xc1515d58, addr=0xc1317c80, uio=0xcc155c4c, top=0x0, control=0x0, flags=0, td=0xc14ed000) at /usr/src/sys/sys/mbuf.h:363 #18 0xc069515c in kern_sendit (td=0xc14ed000, s=5, mp=0xcc155cc4, flags=0, control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:725 #19 0xc0694f8e in sendit (td=0x0, s=0, mp=0xcc155cc4, flags=0) ---Type <return> to continue, or q <return> to quit--- at /usr/src/sys/kern/uipc_syscalls.c:665 #20 0xc06952fb in sendto (td=0x0, uap=0x0) at /usr/src/sys/kern/uipc_syscalls.c:786 #21 0xc08182f0 in syscall (frame= {tf_fs = -1078001617, tf_es = 47, tf_ds = -1078001617, tf_edi = 134746740, tf_esi = 134742096, tf_ebp = -1077941912, tf_isp = -871015052, tf_ebx = -1, tf_ edx = 134732992, tf_ecx = 672691456, tf_eax = 133, tf_trapno = 22, tf_err = 2, t f_eip = 672176607, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941956, tf_ss = 47 }) at /usr/src/sys/i386/i386/trap.c:1004 #22 0x281099df in ?? () ---Can't read userspace from dump, or kernel process--- -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired);Received on Fri Jun 11 2004 - 12:40:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:56 UTC