Another alpha panic

[Andrew Gallatin]

Alan L. Cox writes:
 > Kris Kennaway wrote:
 > > 
 > > Dump of assembler code for function pmap_activate:
 > > 0xfffffc00005cf0b0 <pmap_activate>:     ldah    gp,14(t12)
 > ...
 > > 0xfffffc00005cf160 <pmap_activate+176>: srl     t1,0xd,t1
 > > 0xfffffc00005cf164 <pmap_activate+180>: stq     t1,16(t2)
 > ...
 > I believe that the shift right is the "... >> PAGE_SHIFT" in
 > 
 >      td->td_pcb->pcb_hw.apcb_ptbr =
 >          ALPHA_K0SEG_TO_PHYS((vm_offset_t) pmap->pm_lev1) >> PAGE_SHIFT;
 > 
 > and the store quad is dereferencing "td->td_pcb".  In other words, 
 > td->td_pcb points to never-never land.
 > 

Is it really pointing into never-never land?  The original panic was
that pmap_emulate_reference() was complaining that the page was not
managed..  The physical address 0xb0a0000 is not totally unreasonable,
and would sit around ~176MB into memory.

The fact that the trap was an ALPHA_MMCSR_FOW, and not an
ALPHA_MMCSR_INVALTRANS or ALPHA_MMCSR_ACCESS makes me think that the
kva was also good...

I was wondering if there might be some more insidious pmap corruption
happening.  Or at least why a page in the middle of memory is not
marked as managed.


Drew