OK, here goes.

I just paniced starting build.sh in single user mode with /tmp  
mounted as an MFS file system


Stopped in pid 594.1 (sh) at netbsd:cpu_Debugger+0x4: leave

This is all I got a chance to copy down by hand, the system appears  
to be unable to write a valid core dump.

__main at netbsd:__main
pmap_enter at netbsd:pmap_enter+0x59e
uvm_fault at netbsd:uvm_fault+0x3a
trap() at netbsd:trap+0x36f


Then later when it decides it can't sync:

cpu_debugger+0x4
acquire+0x18d
_lockmgr+0x54e
pmap_clear_attrs+0x76
genfs_putpages+0xc60
VOP_PUTPAGES+0x40
ffs_full_fsync+0x3d7
ffs_fsync+0x4b
VOP_FSYNC+0x4c
ffs_sync+0x27a
sys_sync+0x109
vfs_shutdown+0x6f
cpu_reboot+0x16d
panic+0x109
__main
pmap_enter+0x59e
uvm_fault+0x3ea
trap+0x36f
--- trap (number 6) ---
i486_copyout+0x3d
sysctl_dispath+0x76
sys__sysctl+0xad
syscall_plain+0x1a5
--- syscall (number 202) ---
0xbdbad93b:
db{0}> show registers
ds 0x10
es 0x10
fs 0x30
gs 0x10
edi 0
esi 0
ebp 0xd16496b8
ebx 0xc0857420 pmap_main_lock
edx 0xc081e960 cpu_info_primary
ecx 0x286
eax 0xf8034ef8
eip 0xc045b8b8 cpu_Debugger+0x4
cs 0x8
eflags 0x286
esp 0xd16496b8
ss 0x10
netbsd:cpu_Debugger+0x4: leave


Despite writing the core out to disk, savecore refuses to give me a  
copy of it with different errors all the time

savecore: no core dump
savecore: magic number mismatch (0xbb04 != 08fca0101)
savecore: netbsd: kvm_nlist: bad namelist
savecore: netbsd: _dumpdev not in namelist
savecore: can't find device 2663/787372
savecore: no core dump

On Apr 30, 2005, at 1:11 PM, Chuck Silvers wrote:

> hi,
>
> this message means that somehow we're forgetting that a mapping is  
> supposed
> to be wired, since when we went to unwire it, it wasn't wired anymore.
>
> could you try running with the attached patch?  it'll panic when it  
> sees
> us replacing a wired pmap mapping with a non-wired one, which is  
> legal but
> doesn't happen in practice, so if it happens then it's probably  
> related to
> what you're seeing.
>
> also, could you find out what program is triggering those messages?
> you could set a ddb breakpoint on printf and see what the current  
> process
> is at the time.
>
> -Chuck
>
>
> On Fri, Apr 29, 2005 at 02:30:44PM -0400, Chris Tribo wrote:
>
>> While I was only seeing these infrequently, that is not the case
>> anymore.
>>
>> ...
>> Apr 29 14:25:32 atlantis last message repeated 46 times
>> Apr 29 14:26:27 atlantis last message repeated 65 times
>> Apr 29 14:26:28 atlantis /netbsd: pmap_unwire: wiring for pmap
>> 0xce3c9d48 va 0xbdbcd000 didn't change!
>> Apr 29 14:26:29 atlantis last message repeated 2 times
>> Apr 29 14:26:30 atlantis /netbsd: pmap_unwire: wiring for pmap
>> 0xd1d42130 va 0xbdbcd000 didn't change!
>> Apr 29 14:26:31 atlantis last message repeated 3 times
>> Apr 29 14:26:32 atlantis /netbsd: pmap_unwire: wiring for pmap
>> 0xd1d420cc va 0xbdbcd000 didn't change!
>> Apr 29 14:26:55 atlantis last message repeated 30 times
>> Apr 29 14:26:55 atlantis /netbsd: pmap_unwire: wiring for pmap
>> 0xd1d42068 va 0xbdbcd000 didn't change!
>> Apr 29 14:27:25 atlantis last message repeated 39 times
>> ...
>>
>> It's up to about once a second during compilation of some packages.
>>
>> NetBSD atlantis 3.99.3 NetBSD 3.99.3 (GENERIC.MPACPI.DEBUG) #11: Thu
>> Apr 28 19:17:26 EDT 2005
>>
>>
>
>
> !DSPAM:4273bc47198371411234531!
>
> <diff.x86pmap>
>