<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hello, Sebastian<br><br>I think that this patch is necessary in two reasons.<br><br>In general view, if we have a conditional branch, we want, obviously, to<br>invoke two instruction siquences with different results. Without this <br>patch we clear EF bit in conditional branch in any case and I think this<br>is not that we want regardless if this causes error or not.<br><br>More specific technical reason is that there is a real situation - I have<br>debugging info and instruction trace (which was got with hardware debugging<br>module DSU on LEON3) where I see that sometimes we return from interrupt <br>with cleared PSR[EF] flag in the floating point task (I described this a <br>bit in my first message) and this causes excessive lazy fp switch <br></div><div class="gmail_default" style="font-family:monospace,monospace">(previously I had system crash before fixing lazy fp switch syscall).<br><br>Just now I can't give very detail description why and how this happens, <br></div><div class="gmail_default" style="font-family:monospace,monospace">but bellow I put part of LEON3 DSU trace for mentioned above situation<br><br>This is part of code which I use to investigate problem which we talk about<br><br>...<br>4f102d8c: 95 a2 88 58 faddd %f10, %f24, %f10<br>4f102d90: 80 a3 00 09 cmp %o4, %o1<br>4f102d94: 91 a2 09 54 fmuld %f8, %f20, %f8<br>4f102d98: 95 a0 05 4a fsqrtd %f10, %f10<br>4f102d9c: d5 3b bf f8 std %f10, [ %sp + -8 ]<br>4f102da0: 01 00 00 00 nop <br>4f102da4: 91 a2 08 4a faddd %f8, %f10, %f8<br>4f102da8: 95 a4 89 c8 fdivd %f18, %f8, %f10<br>4f102dac: d5 3b bf f8 std %f10, [ %sp + -8 ]<br>4f102db0: 01 00 00 00 nop <br>4f102db4: d1 38 7f 70 std %f8, [ %g1 + -144 ]<br>4f102db8: d1 18 80 00 ldd [ %g2 ], %f8 <--- Interrupt<br>4f102dbc: 91 a2 08 ce fsubd %f8, %f14, %f8<br>4f102dc0: 91 a2 09 4a fmuld %f8, %f10, %f8<br>4f102dc4: d1 38 7f 58 std %f8, [ %g1 + -168 ]<br>4f102dc8: d1 18 a0 08 ldd [ %g2 + 8 ], %f8<br>4f102dcc: 91 a2 08 cc fsubd %f8, %f12, %f8<br>...<br><br>Part of trace<br><br><br>463493523 4F06D6A0 restore [00000000]<br>463493524 4F06D6A4 ldd [%g1], %l0 [0000000C 4F57C348]<br>463493526 4F06D6A8 ldd [%g1 + 0x8], %l2 [0406CE9C 0406CE78]<br>463493528 4F06D6AC ldd [%g1 + 0x10], %l4 [0406CE54 0406CE30]<br>463493530 4F06D6B0 ldd [%g1 + 0x18], %l6 [4F57C528 0406CE84]<br>463493533 4F06D6B4 ldd [%g1 + 0x20], %i0 [0406CF78 4F534BB0]<br>463493610 4F06D6B8 ldd [%g1 + 0x28], %i2 [0408CDC0 0406CE24]<br>463493612 4F06D6BC ldd [%g1 + 0x30], %i4 [00000001 00000003]<br>463493616 4F06D6C0 ldd [%g1 + 0x38], %fp [4F534B40 4F103868]<br>463493620 4F06D6C4 save [00000000]<br>463493622 4F06D6C8 mov %l0, %psr [F34000C6] <-- (1)<br>463493625 4F06D6CC nop [00000000]<br>463493702 4F06D6D0 nop [00000000]<br>463493703 4F06D6D4 nop [00000000]<br>463493717 4F06D6D8 ld [%g1 + 0x6C], %g1 [0408D148]<br>463493718 4F06D6DC jmp %l1 [4F06D6DC]<br>463493719 4F06D6E0 rett %l2 [4F102DC0]<br>463493722 4F102DBC fsubd %f8, %f14, %f8 [ TRAP ] <-- (2)<br>463493728 04000040 mov %psr, %l0 [F34000C6]<br>463493729 04000044 sethi %hi(0x4F06D800), %l4 [4F06D800]<br>463493730 04000048 jmp %l4 + 0x20 [04000048]<br>463493731 0400004C sethi %hi(0x1000), %l3 [00001000]<br><br><br>Here (1) we see that restored PSR[EF] == 0 and directly after return from <br></div><div class="gmail_default" style="font-family:monospace,monospace">interrupt (2) we fall in lazy fp switch syscall<br><br>To be honest, I cant say that I fully understand how _ISR_Handler procedure<br>works, therefore your help would be very desirable.<br><br>When I get more debugging information, I'll provide it. But it takes some<br>time.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><font size="2" face="verdana, sans-serif">--</font></div><div><font size="2" face="verdana, sans-serif">Best regards,</font></div><font size="2" face="verdana, sans-serif">Maksim Kozlov</font></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 6 Jun 2019 at 16:13, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Maksim,<br>
<br>
On 06/06/2019 14:43, Maksim Kozlov wrote:<br>
> On Thu, 6 Jun 2019 at 09:57, Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
><br>
><br>
><br>
> On 05/06/2019 21:22, Maksim E. Kozlov wrote:<br>
> > ---<br>
> > cpukit/score/cpu/sparc/cpu_asm.S | 3 ++-<br>
> > 1 file changed, 2 insertions(+), 1 deletion(-)<br>
> ><br>
> > diff --git a/cpukit/score/cpu/sparc/cpu_asm.S<br>
> b/cpukit/score/cpu/sparc/cpu_asm.S<br>
> > index 2f3ad24510..69bbfb2748 100644<br>
> > --- a/cpukit/score/cpu/sparc/cpu_asm.S<br>
> > +++ b/cpukit/score/cpu/sparc/cpu_asm.S<br>
> > @@ -682,10 +682,11 @@ isr_dispatch:<br>
> > ld [%g6 + SPARC_PER_CPU_FP_OWNER_OFFSET], %l7<br>
> > cmp %l6, %l7<br>
> > bne .Ldisable_fp<br>
> > - andn %l0, %l5, %l0<br>
> > + nop<br>
><br>
> Wouldn't it be sufficient to change this to<br>
><br>
> bne,a .Ldisable_fp<br>
> andn %l0, %l5, %l0<br>
><br>
> ?<br>
><br>
><br>
> Yes, you are right, this is my inattentiveness, and it is enough just <br>
> to set<br>
> an annul flag.<br>
> If it is needed, I attached modified patch, but if you prefer, you can <br>
> just add<br>
> this flag yourself.<br>
<br>
I still have problems to understand why this patch is necessary. The <br>
current code is like this:<br>
<br>
/*<br>
* If we are still the floating point unit owner, then reset the<br>
* floating point unit owner to NULL, otherwise clear PSR[EF] <br>
in the<br>
* interrupt frame and let the FP disabled system call do the <br>
floating<br>
* point context save/restore.<br>
*/<br>
ld [%g6 + SPARC_PER_CPU_FP_OWNER_OFFSET], %l7<br>
cmp %l6, %l7<br>
bne .Ldisable_fp<br>
andn %l0, %l5, %l0<br>
<br>
---> No matter what happens, the PSR[FP] is now cleared in %l0.<br>
---> In this path we are the FPU owner and direct jump to ...<br>
<br>
ba .Lthread_dispatch_done<br>
st %g0, [%g6 + SPARC_PER_CPU_FP_OWNER_OFFSET]<br>
<br>
.Ldisable_fp:<br>
ba .Lthread_dispatch_done<br>
st %l0, [%fp + ISF_PSR_OFFSET]<br>
.Lnon_fp_thread_dispatch:<br>
<br>
call SYM(_Thread_Do_dispatch)<br>
mov %g6, %o0<br>
<br>
---> ... here. From now on %l0 is no longer used and ...<br>
<br>
#if SPARC_HAS_FPU == 1<br>
.Lthread_dispatch_done:<br>
#endif<br>
<br>
[... %l0 not used ]<br>
<br>
---> ... here it is loaded:<br>
<br>
ldd [%fp + ISF_PSR_OFFSET], %l0 ! restore psr, PC<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div>