Opened 14 months ago

Last modified 14 months ago

#15210 new bug

KDL: Unexpected exception "SIMD Floating-Point Exception" occurred in kernel mode!

Reported by: konrad Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


If you run Qemu with SMP larger than 2, Haiku crashes.

This one KDLs: qemu-system-x86_64 -drive file=haiku.img,format=raw -m 8192 -soundhw hda -usb -accel hvf -cpu host -smp 4 -rtc base=utc,clock=host

changing to -smp 2 works.

Attachments (1)

serial.txt (33.4 KB ) - added by konrad 14 months ago.
serial output

Download all attachments as: .zip

Change History (9)

by konrad, 14 months ago

Attachment: serial.txt added

serial output

comment:1 by waddlesplash, 14 months ago

Keywords: qemu removed
Summary: KDL in QemuKDL: Unexpected exception "SIMD Floating-Point Exception" occurred in kernel mode!

There's a bunch of floating-point math in there, but no divides by non-constants. That it works with 2 cores but not 4 is especially strange, and likely implies a bug in our multicore logic, or (more likely, since no-one has ever seen this elsewhere) in QEMU's HVF usage

comment:2 by tqh, 14 months ago

I thought we avoided FP/SIMD in the kernel?

comment:3 by waddlesplash, 14 months ago

We have never had a policy of avoiding FP. A large number of things in kernel-mode (the USB stack as seen here is one instance) use floating-point math.

We also do not have any policy (or, really, any reason, since SSE2 is part of the baseline x64) to avoid SIMD in the kernel; I think it's enabled (since pdziepak's scheduler changes) inside the bootloader just before the kernel is called. GCC 6+ by default will vectorize certain operations; seems that's what is occurring here.

comment:4 by tqh, 14 months ago

Do we really save and restore that properly. I think they propably shouldn't be there. I was taught to never ever do that in kernel and think most OS'es avoid it. In PS/2 driver there is even fake FP handling.

comment:5 by tqh, 14 months ago

Looked it up, saving restoring fp (and simd on 32bit) is so expensive it is not done on context switching. Therefore you need to write code that save/restore them perfetly on all exit cases and without messing up stack order. So it's just something you should avoid. SIMD on 64 bit is fine though.

Havn't looked at our own context-switching though.

comment:6 by waddlesplash, 14 months ago

As I said already, pdziepak made changes to enable this even earlier in the boot than it was before; we definitely support this properly in kernel mode and many other things would have broken if we didn't:

comment:7 by waddlesplash, 14 months ago

The PS/2 driver's fake FP probably dates from the days we ran Haiku code under BeOS, which (I don't believe?) supported floating-point, indeed. We can probably get rid of that fake code and use the real thing now.

comment:8 by tqh, 14 months ago

Ah nice. PS/2 code will be moved out of kernel at some point. Similar code exists in userland already.

Note: See TracTickets for help on using tickets.