Subject: panic: vm_pager_map_pages: page not busy
To: None <port-sparc@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: port-sparc
Date: 02/28/1996 17:06:35
Okay, this makes four for four, it ain't coincidence.
I just built a kernel for debugging (makeoptions DEBUG="-g" in the
config file). Everything went fine, right up to the very last step.
It did the "cp netbsd netbsd.gdb" and that was fine, then it did "strip
-d netbsd" and crashed. I removed netbsd and tried again, and it
crashed again. And again. The fourth time I checked, and netbsd and
netbsd.gdb had the same size (I didn't check whether they were actually
identical), so I just ran "strip -d netbsd" by hand. And it crashed a
fourth time. I took a kernel coredump and rebooted; after that
rebooting, netbsd and netbsd.gdb _are_ identical.
The stack trace in the coredump is
#0 0xf8007dd0 in snapshot ()
#1 0xf8007dd8 in snapshot ()
#2 0xf80ff324 in boot ()
#3 0xf802bf88 in panic ()
#4 0xf80cf4a4 in vm_pager_map_pages ()
#5 0xf80d113c in vnode_pager_setsize ()
#6 0xf80b12e8 in ffs_truncate ()
#7 0xf80c0c70 in ufs_setattr ()
#8 0xf80492b0 in sys_ftruncate ()
#9 0xf8107520 in syscall ()
#10 0xf8006714 in trapbase ()
When I run "ktrace strip -d netbsd" instead, kdump output (after
rebooting, of course) contains only the following, after skipping all
the shared library syscalls.
133 strip CALL open(0xf7fff785,0x2,0x2948)
133 strip NAMI "netbsd"
133 strip RET open 3
133 strip CALL fstat(0x3,0xf7fff640)
133 strip RET fstat 0
133 strip CALL mmap(0,0xa8f972,0x3,0x1,0x3,0,0,0)
133 strip RET mmap 67903488/0x40c2000
133 strip CALL __sysctl(0xf7fff4f8,0x2,0x40b34f0,0xf7fff4f4,0,0)
133 strip RET __sysctl 4
133 strip CALL break(0x6390)
133 strip RET break 0
133 strip CALL break(0x6ffc)
133 strip RET break 0
133 strip CALL break(0x807ffc)
133 strip RET break 0
133 strip CALL ftruncate(0x3,0,0,0x1594f3)
I suspect this is Yet Another VM Problem. I've tried to deliberately
provoke it, by ftruncate()ing an mmap()ed file, with no success...but
that strip -d command has crashed the machine every time I've tried it.
Clues, anyone? (At this point, I'd even like patches to make strip not
use mmap, so I can get a usable debugging kernel!)
der Mouse
mouse@collatz.mcrcim.mcgill.edu