From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Mosberger Date: Thu, 20 Nov 2003 18:47:50 +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 >>>>> 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