Re: Problems using psr.dd

[Keith Owens <kaos@sgi.com>]

On Thu, 20 Nov 2003 10:47:50 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Thu, 20 Nov 2003 18:52:33 +1100, Keith Owens <kaos@sgi.com> said:
>  Keith> Beware of doing too much activity in the hardware breakpoint
>  Keith> handler.  I will create a patch against traps.c to detect a
>  Keith> return with psr.dd set and issue loadrs to ensure that the
>  Keith> RSE problem does not bite us.
>
>I'm still not sure what's triggering the spurious fault:
>
> (1) The RSE activity generated for restoring the current frame, or
> (2) The RSE activity generated by the alloc instruction that eventually
>     follows the instruction to which "rfi" returns to.

It has to be (1).  psr.dd is getting cleared before the st8 is being
executed.  Just to be sure, I inserted 20 bundles of nop before and
after 'victim = 1;', the problem still occurs.

>Unfortunately, the description of Erratum 11 isn't terribly clear to
>me.  It says:
>
>	... The rfi instruction is followed by additional instructions
>	that generate register stack (RSE) activity (alloc, flushrs,
>	br.ret).
>
>I assume "followed" is referring to execution order, not program order
>(i.e., inserting nop's around the "rfi" isn't going to do us any
>good).  In your (original) case, the "rfi" is followed by a store
>instruction, br.call, then alloc.  From reading the description, I
>wouldn't have expected this to trigger the Erratum, but perhaps it
>does.  Can someone clarify?

Agreed that it is unclear.  Given the workaround for errata 11 (add 4
nop bundles around rfi) I interpret errata 11 as an instruction read
ahead problem, where RSE instructions in the bundles after rfi could be
read, decoded and trip RSE activity even though they were not executed.
In any case, I added 20 nop bundles around the trapping instruction and
it made no difference.

Arch volume 2, section 5.3 is quite explicit, "A non-faulting mandatory
RSE load will clear PSR.da and PSR.dd".  This does not appear to be a
problem when returning to user space with these bits set, probably
because the context switch does loadrs.  AFAICT it is only an issue
when using hardware debug registers on the kernel itself.  traps.c has
to detect that it is returning to kernel state with either of these
bits set and issue loadrs to ensure that the rfi does not require RSE
loads.  Patch in progress.