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