Today's -current panics
othermark
atkin901 at yahoo.com
Fri Jun 11 14:40:29 GMT 2004
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);
More information about the freebsd-current
mailing list