Re: [parisc-linux] Debugging 64-bit kernel crashes involving tst-fork1.

Re: [parisc-linux] Debugging 64-bit kernel crashes involving tst-fork1.

[James Bottomley]

On Tue, 2007-02-20 at 13:34 -0500, Carlos O'Donell wrote:
> sr00-03  00000000000e2800 00000000000e2800 0000000000000000 00000000000e2800
> sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 
> IASQ: 0000000000000000 0000000000000000 IAOQ: 0000000040334894 0000000040334898
>  IIR: 0ec25033    ISR: 00000000000e2800  IOR: 00000000000aac8c
                         ^^^^^^^^^^^^^^^^
This clearly identifies the faulting space

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

Or, that %cr8 somehow doesn't contain the space 00000000000e2800 ... but
I think that's a bit more unlikely.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Debugging 64-bit kernel crashes involving tst-fork1.

[James Bottomley]

On Fri, 2007-02-23 at 15:23 -0600, James Bottomley wrote:
> 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).
> 
> Or, that %cr8 somehow doesn't contain the space 00000000000e2800 ... but
> I think that's a bit more unlikely.

Actually, I've changed my mind ... I don't think there's any way we can
get the TLB marked with the wrong Access ID (but if we do there's no way
to get it out of the fault data).  Could you add a printout of %cr8 and
current->comm to the data for the protection id trap in
arch/parisc/kernel/traps.c and tell me what it prints?

Thanks,

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Debugging 64-bit kernel crashes involving

[John David Anglin]

> >  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                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux