On Thu, 24 Aug 2000, Manuel Bouyer wrote:

> Hi,
> I installed the 1.5_ALPHA2 sparc64 snapshot on a Ultra1/143:
> Sun Ultra 1 SBus (UltraSPARC 143MHz), No Keyboard
> OpenBoot 3.11, 128 MB memory installed, Serial #8793120.
> Ethernet address 8:0:20:86:2c:20, Host ID: 80862c20.
> 
> I just got a panic while running a ftp -o - ... | tar xvzpf -:
> 'EPSV': command not understood.
> trap type 0x34: pc=f100bfbc npc=f100bfc0 pstate=44580006<PRIV,IE>
> kernel trap 34: mem address not aligned
> Stopped in tar at       pseg_get:       ldx             [%o0 + 0x8], %o2

No, this one's new.  The machine's trying to look up a PTE from some pmap
but the pointer to the pmap is unaligned.

> db> tr
> pmap_enter_pv(f19e8000, 284000, 102ac000, 0, 101d0a00, a10) at pmap_enter_pv+0x1
> 4c
> pmap_enter(f19e8000, 284000, 102ac000, 2, f149ed68, 0) at pmap_enter+0x358
> uvm_fault(f18e38a0, 4, f1499958, f5e5d500, 3, 27e000) at uvm_fault+0x1980
> data_access_fault(68, 2840cd, 152528, f641ded0, 0, 2840cd) at data_access_fault+0x488
> Ldatafault_internal(284000, 26dab0, 18, 284010, 267c00, 4) at Ldatafault_internal+0xe0
> db> 

Since it's in pmap_enter_pv() it may be that the bad pmap came from the
pv_list or from pmap_kernel(), or curproc->p_vmspace.

Next time this happens could you:

1) `mach tf' to get the trapframe of the fault.

2) check curproc's p_vmstate to make sure it has a correct pmap pointer.

3) if you can figure out the address of the original fault (possibly from
`mach tf /u') you can use `mach pv <page>' to dump the pv_list for that
page.

Eduardo Horvath