RE: Problems using psr.dd

["Seth, Rohit" <rohit.seth@intel.com>]

Erratum 11 applies to the cases where rfi is followed by RSE generating
instruction in static code stream (i.e. in the source).  Have not looked
at the Keith's changes but hopefully he has not put any instruction like
alloc after rfi in the source.

Thanks,
rohit

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org [mailto:linux-ia64-
> owner@vger.kernel.org] On Behalf Of David Mosberger
> Sent: Thursday, November 20, 2003 10:48 AM
> To: Keith Owens
> Cc: linux-ia64@vger.kernel.org
> Subject: Re: Problems using psr.dd
> 
> >>>>> On Thu, 20 Nov 2003 18:52:33 +1100, Keith Owens <kaos@sgi.com>
said:
> 
>   Keith> If there is enough RSE activity during the hardware
>   Keith> breakpoint handler to flush the registers at the time of the
>   Keith> breakpoint then returning with psr.db = 1 and psr.dd = 1 to
>   Keith> step over the hardware breakpoint will not work.  The RSE
>   Keith> activity that occurs as the flushed registers are restored is
>   Keith> counted as a valid instruction, psr.dd is cleared, the
>   Keith> original instruction is reexecuted and it trips again.
> 
>   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.
> 
> 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?
> 
> 	--david
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html