Alex Zepeda wrote:

[ kdbg output removed]

>The most applicable dmesg output I could find was:
>Memory modified after free 0xc215d000(8188)
>panic: Most recently used by none
I've gotten this same panic with a kernel+world cvsup'd from Sun Jul 21 
23:43 EDT, just got one a few minutes ago.  I'm in the kernel debugger 
since I haven't been able to get a dump to work since - well ever I 
guess :-/  so I'll echo Alex's offer to entertain any debugger requests. 
 Interesting thing is the apparent page fault I got when I tried 'ps' at 
the "db>" prompt:

lock order 
 1st 0xc4758160 process lock (process lock) @ 
 2nd 0xc0314880 filelist lock (filelist lock) @ 
/usr/src/sys/vm/uma_core.c:1332: could sleep with "process lock" locked 
from /usr/src/sys/kern/kern_exec.c:335
J/usr/src/sys/vm/uma_core.c:1332: could sleep with "process lock" locked 
from /usr/src/sys/kern/kern_exec.c:335
/usr/src/sys/vm/uma_core.c:1332: could sleep with "process lock" locked 
from /usr/src/sys/kern/kern_exec.c:335
Memory modified after free 0xc50e3d00(252)
panic: Most recently used by kqueue

cpuid = 0; = 01000000
Stopped at      Debugger+0x46:  xchgl   %ebx,in_Debugger.0
db> ps
  pid   proc     addr    uid  ppid  pgrp  flag  stat wmesg   wchan   cmd
80562 c4883558 de3fd000    0 80533     0 0006002  New

Fatal trap 12: page fault while in kernel mode
cpuid = 0; = 01000000
fault virtual address   = 0x48
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc014111b
stack pointer           = 0x10:0xde26fa18
frame pointer           = 0x10:0xde26fa28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 80561 (sh)
kernel: type 12 trap, code=0
Stopped at      Debugger+0x46:  xchgl   %ebx,in_Debugger.0
db> show locks
exclusive sleep mutex Giant r = 0 (0xc03179e0) locked @ 
db>  bt
No such command
db> trace
Debugger(c02e10fa) at Debugger+0x46
panic(c02f7408,c02ddda0,c02f73e0,c50e3d00,fc) at panic+0xde
mtrash_ctor(c50e3d00,100,0) at mtrash_ctor+0x4c
uma_zalloc_arg(c082dc00,0,0) at uma_zalloc_arg+0xff
malloc(dc,c0314580,0,c50ffe00,1) at malloc+0x68
fdcopy(c467de40,c50ffe34,0,c02de191,1c9) at fdcopy+0x61
fork1(c467de40,14,de26fce0,c03179e0,0) at fork1+0x6c7
fork(c467de40,de26fd14,0,0,202) at fork+0x2a
syscall(2f,2f,2f,80f23ac,80f23ac) at syscall+0x23c
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (2, FreeBSD ELF32, fork), eip = 0x8076bb3, esp = 0xbfbff30c, 
ebp = 0xbfbff328 ---

I'm anxious to get something working, at least the dump+gdb/gdb52 
facility, so I can do some type of debugging; it's either that or kill 
the 150 day uptime FreeBSD-4.4 400MHz box and swap the two, but I was 
hoping to debug some SMP on the new box </whine>.

Anthony Jenkins

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to