Subject: Re: pmap_unwire: wiring for pmap 0xfoo va 0xbar didn't change!
To: Chuck Silvers <chuq@chuq.com>
From: Chris Tribo <ctribo@dtcc.edu>
List: current-users
Date: 05/12/2005 13:39:46
Here goes attempt number two. Now that I can use a USB keyboard in  
ddb, I set ddb.onpanic back to 1. I'm in single user with a 32 MB mfs  
mounted /tmp. The only other processes running are init and sh. ps  
shows that we're in sh at the moment.

cpu_Debugger(c0859480,0,c07cb200,bfc00000,d165de68) at  
netbsd:cpu_Debugger+0x4
panic(c0801940,c0749b15,c07cb9a0,c07cb200,cd7) at netbsd:panic+0x121
__main(c0749b15,c07cb200,cd7,c07cb9a0,ce3c8620) at netbsd:__main
pmap_enter(ce3c9190,bdbcd000,7b4ea000,3,22) at netbsd:pmap_enter+0x59e
uvm_fault(ce3c8540,bdbcd0000,0,2,2) at netbsd:uvm_fault+0x3ea
trap() at netbsd:trap+0x36f
--- trap (number 6) ---
i486_copyout(d1665efc,0,bdbcdb8c,d1665ef0,0) at netbsd:i486_copyout+0x3d
sysctl_dispatch(d1665ef4,2,bdbcdb8c,d1665f5c,c0813918,282) at  
netbsd:sys_sysctl+0xad
syscall_plain() at netbsd:syscall_plain+0x1a5
--- syscall (number 202) ---
0xbdbad93b:

I did manage to get a core dump.

panic: kernel %sassertion "%s" failed: file "%s", line %d
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xc0ab1000 in ?? ()
#2  0xc045e979 in cpu_reboot (howto=260, bootstr=0x0)
     at /usr/src/sys/arch/i386/i386/machdep.c:752
#3  0xc0364f75 in db_reboot_cmd (addr=1, have_addr=0, count=-1068124166,
     modif=0xd16658ac "@?\210??Xf?\001") at /usr/src/sys/ddb/ 
db_command.c:694
#4  0xc0364abb in db_command (last_cmdp=0xc0812a44,  
cmd_table=0xc0646060)
     at /usr/src/sys/ddb/db_command.c:469
#5  0xc03647cb in db_command_loop () at /usr/src/sys/ddb/db_command.c: 
260
#6  0xc03678db in db_trap (type=5, code=0) at /usr/src/sys/ddb/ 
db_trap.c:101
#7  0xc045beb2 in kdb_trap (type=5, code=0, regs=0xd1665b00)
     at /usr/src/sys/arch/i386/i386/db_interface.c:225
#8  0xc0469368 in trap (frame=0xd1665b00)
     at /usr/src/sys/arch/i386/i386/trap.c:270
#9  0xc010bdd2 in calltrap ()
#10 0xc03b9aa9 in panic (
     fmt=0xc0801940 "kernel %sassertion \"%s\" failed: file \"%s\",  
line %d")
     at /usr/src/sys/kern/subr_prf.c:242
#11 0xc06165e4 in __assert (t=0xc0749b15 "diagnostic ",
     f=0xc07cb200 "/usr/src/sys/arch/i386/i386/pmap.c", l=3287,
     e=0xc07cb9a0 "(opte & PG_W) == 0 || (npte & PG_W) != 0")
     at /usr/src/sys/lib/libkern/__assert.c:45
#12 0xc04665a6 in pmap_enter (pmap=0xce3c9190, va=3183267840,  
pa=2068750336,
     prot=3, flags=34) at /usr/src/sys/arch/i386/i386/pmap.c:1386
#13 0xc043d6ba in uvm_fault (orig_map=0xce3c8540, vaddr=3183267840,
     fault_type=0, access_type=2) at /usr/src/sys/uvm/uvm_fault.c:1245
#14 0xc0469603 in trap (frame=0xd1665de4)
     at /usr/src/sys/arch/i386/i386/trap.c:583
#15 0xc010bdd2 in calltrap ()
#16 0xc03abd86 in sysctl_dispatch (name=0xd1665ef4, namelen=2,
     oldp=0xbdbcdb8c, oldlenp=0xd1665ef0, newp=0x0, newlen=0,  
oname=0xd1665ef4,
     l=0xce3cb9cc, rnode=0xc3aeb240) at /usr/src/sys/kern/ 
kern_sysctl.c:433
#17 0xc03abc39 in sys___sysctl (l=0xce3cb9cc, v=0xd1665f64,  
retval=0xd1665f5c)
     at /usr/src/sys/kern/kern_sysctl.c:302
#18 0xc0468d2d in syscall_plain (frame=0xd1665fa8)
     at /usr/src/sys/arch/i386/i386/syscall.c:161

(gdb) list *(i486_copyout+0x3d)
No source file for address 0xc0100491.



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>
>