Another alpha panic

[Alan Cox]

On Fri, Apr 16, 2004 at 10:41:22AM -0400, Andrew Gallatin wrote:
> 
> 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...
> 

Here is an observation that may or may not be related: The alpha pmap
doesn't implement the PG_UNMANAGED flag on vm_pages.  So, it instantiates
pv entries even though the machine-independent VM says not to.

Fixing this should be mechanical in nature: Search for all uses
of PG_UNMANAGED in amd64's or i386's and change alpha's pmap accordingly.
Volunteer?  I can review the patch but not test it.

Alan