In article <20051020131459.GB16769@snark.ptc.spbu.ru>,
Valeriy E. Ushakov <uwe@ptc.spbu.ru> wrote:
>On Wed, Oct 19, 2005 at 22:30:50 +0100, David Laight wrote:
>
>> That value (in %g1) should (probably) never ever end up in a register
>> in user-space.
>
>Right.  And the address itself is weird.  It's an address of an
>instruction in a delay slot in some unrelated inet6 function.  I don't
>know how it can end up in a register even in the kernel.  The only
>possibility that comes to mind is that a trap/interrupt happens while
>that address is the npc (hardware will stuff it in %l2 before entering
>trap handler) and then it ends up in the register through some
>mischief.
>
>
>> Those values for pc and npc are extremely unlikely to end up in the kernel.
>> Two (obvious) possibilities:
>> a) a hardware interrupt
>> b) a fault on the previous instruction that happens after pc is incremented.
>
>According to the trap information the fault is synchronous, so either
>pc/npc are bogus, or there's a i-cache issue.

I would suspect an i-cache issue. Can you reproduce the problem if you flush
the cache on each syscall?

christos