From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Owens Date: Thu, 20 Nov 2003 23:15:55 +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 10:47:50 -0800, David Mosberger wrote: >>>>>> On Thu, 20 Nov 2003 18:52:33 +1100, Keith Owens 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.