On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov <kostikbel_at_gmail.com> > wrote: > > > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote: > > > The latest VM snapshot > > (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2) > > > instapanics on boot: > > > > > > panic: Unregistered use of FPU in kernel > > > > > > stack trace: > > > ... > > > sse42_crc32c > > > readsuper > > > ffs_sbget > > > g_label_ufs_taste_common > > > g_label_taste > > > g_new_provider_event > > > g_run_events > > > fork_exit > > > ... > > > > > > Has anybody touched this area recently? I'll try to narrow down the > > commit > > > range. > > > > Start with disassembling the faulting instruction. I suspect that somehow > > vital compiler switches like -mno-sse got omitted in the build. > > > > No problem with compiler switches here. The C file uses inline assembly to > generate a crc32q instruction, in crc32_sse42.c:257. But why would that > generate a floating point exception? The instruction doesn't appear to be > using any floating point registers. This is on a Kaby Lake CPU. > > crc32q %rsi, %rbx No idea, this instruction does not generate #NP at all. Provide exact script of the panic and backtrace, together with the disassembly of the function which contained the faulted instruction. Do disassemble from ddb, in case text was corrupted.Received on Thu Sep 26 2019 - 15:29:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC