From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Seth, Rohit" Date: Thu, 20 Nov 2003 20:29:42 +0000 Subject: RE: Problems using psr.dd Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-ia64@vger.kernel.org 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 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