There are no bugs in qemu. Just hardware.

What was in xmm0?

ron

On Fri, Feb 26, 2016 at 2:54 PM Barret Rhoden <[email protected]> wrote:

> On 2016-02-26 at 14:24 Kevin Klues <[email protected]> wrote:
> > Don't forget about this fun little bug:
> >
> >
> https://groups.google.com/forum/#!searchin/akaros/SSE/akaros/FEIQbLixkm8/tmSagO31AwAJ
>
> Good times!
>
> > Might be related?
>
> I hope not!
>
> The problem just popped up after Mike's recent FP work, so I'm hoping
> its something related to the different save/restore style.
>
> Barret
>
>
> >
> > On Fri, Feb 26, 2016 at 2:21 PM, Barret Rhoden <[email protected]>
> > wrote:
> > > lock_test is trapping with a SIMD floating point error (trap 19)
> > > around here:
> > >
> > > 40589d:   f2 0f 51 c0             sqrtsd %xmm0,%xmm0
> > >
> > > Maybe whatever exception that is thrown used to be masked, but isn't
> > > anymore?  Does the new XSAVE stuff treat MXCSR differently?
> > >
> > > Or perhaps we were doing something wrong before, and the new FP code
> > > exposes it?
> > >
> > > To reproduce:
> > > / $ m px (for better debugging output)
> > > / $ lock_test -w7 -l10000 -tmcspdr -p10
> > >
> > > HW TRAP frame (partial) at 0xffffffffc6944ad8 on core 5
> > >   rax  0x00000000001c835e
> > >   rbx  0x00007f7fffbfee00
> > >   rcx  0x00000000000002a1
> > >   rdx  0x0000000000000174
> > >   rbp  0x00007f7fffbfeda0
> > >   rsi  0x0000081db323551c
> > >   rdi  0x0000000000620620
> > >   r8   0x0000000000000000
> > >   r9   0x0000000000000000
> > >   r10  0x0000000000000000
> > >   r11  0x0000000000000200
> > >   r12  0x0000000000000064
> > >   r13  0x0000000000620620
> > >   r14  0x0000000000000008
> > >   r15  0x0000000000000064
> > >   trap 0x00000013 SIMD Floating-Point Exception
> > >   gsbs 0x0000000000000000
> > >   fsbs 0x0000000000000000
> > >   err  0x--------00000000
> > >   rip  0x000000000040589d
> > >   cs   0x------------0023
> > >   flag 0x0000000000010202
> > >   rsp  0x00007f7fffbfed10
> > >   ss   0x------------001b
> > > err 0x0 (for PFs: User 4, Wr 2, Rd 1), aux 0x0000000000000000
> > > Addr 0x000000000040589d is in lock_test at offset 0x000000000000589d
> > >
> > >
> > > i tried making sure the mxcsr was the default value before the
> > > xsave64, but that didn't do the trick.
> > >
> > >         incidentally, if you want to do an ldmxcsr on Qemu, you need
> > >         to:
> > >                 lcr4(rcr4() | CR4_OSFXSR | CR4_OSXMME |
> > > CR4_OSXSAVE);
> > >
> > >         otherwise you get an Invalid Opcode.  It doesn't seem to be
> > >         that way on hardware.  Ah, bugs in qemu?
> > >
> > > anyway, i hacked up the trap handler to print out a little more:
> > >
> > > --- a/kern/arch/x86/trap.c
> > > +++ b/kern/arch/x86/trap.c
> > > @@ -389,7 +389,8 @@ static void trap_dispatch(struct hw_trapframe
> > > *hw_tf) handled = __handle_page_fault(hw_tf, &aux);
> > >             break;
> > >         case T_FPERR:
> > > +       case T_SIMDERR:
> > >             handled = try_handle_exception_fixup(hw_tf);
> > >             if (!handled)
> > >                 handle_fperr(hw_tf);
> > >             break;
> > >
> > >
> > > HW TRAP frame (partial) at 0xffff80013fd58f40 on core 7
> > >   rax  0x0000000000a45061
> > >   rbx  0x00007f7fffbfee10
> > >   rcx  0x0000000000001b25
> > >   rdx  0x00000000000000a9
> > >   rbp  0x00007f7fffbfedb0
> > >   rsi  0x0000004fc30822de
> > >   rdi  0x0000000000620390
> > >   r8   0x0000000000000000
> > >   r9   0x0000000000000000
> > >   r10  0x0000000000000000
> > >   r11  0x0000000000000200
> > >   r12  0x00000000000003e8
> > >   r13  0x0000000000620390
> > >   r14  0x0000000000000007
> > >   r15  0x00000000000003e8
> > >   trap 0x00000013 SIMD Floating-Point Exception
> > >   gsbs 0x0000000000000000
> > >   fsbs 0x0000000000000000
> > >   err  0x--------00000000
> > >   rip  0x000000000040589d
> > >   cs   0x------------0023
> > >   flag 0x0000000000010202
> > >   rsp  0x00007f7fffbfed20
> > >   ss   0x------------001b
> > > Core 7: FP ERR, CW: 0x037f, SW: 0x0000, MXCSR 0x00000020
> > > Core 7: The following faults are unmasked:
> > > Killing the process.
> > >
> > > That shit was made for floating point.  SIMD errors might be
> > > different.
> > >
> > > Any ideas?
> > >
> > > Barret
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Akaros" group. To unsubscribe from this group and stop
> > > receiving emails from it, send an email to
> > > [email protected]. To post to this group, send
> > > email to [email protected]. For more options, visit
> > > https://groups.google.com/d/optout.
> >
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to