Don't forget about this fun little bug: https://groups.google.com/forum/#!searchin/akaros/SSE/akaros/FEIQbLixkm8/tmSagO31AwAJ
Might be related? 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. -- ~Kevin -- 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.
