Re: Debugging 64-bit kernel crashes involving

> >  IIR: 0ec25033    ISR: 00000000000e2800  IOR: 00000000000aac8c
>                          ^^^^^^^^^^^^^^^^
> This clearly identifies the faulting space

This is for
	ldb,ma 1(sr1,r22),r19

> >  CPU:        0   CR30: 000000009ad38000 CR31: 0000000040848000
> >  ORIG_R28: 00000000407f6c00
> >  IAOQ[0]: pa_memcpy+0x114/0x2d0
> >  IAOQ[1]: pa_memcpy+0x118/0x2d0
> >  RP(r2): copy_from_user+0x34/0x40
> > Backtrace:
> 
> Which means that somehow a TLB entry got inserted for address
> 00000000000aac8c in space 00000000000e2800 which didn't have the correct
> Access ID (which for us should have been the space 00000000000e2800).

Just wondering why a protection id trap causes the system to eat sparcs...
Is this a combined TLB issue?

Dave
-- 
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)