Re: panic: Unregistered use of FPU in kernel
On Fri, Sep 27, 2019 at 5:50 AM Andriy Gapon wrote: > On 26/09/2019 18:45, 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. > > Given the qcow2 image, is this in a VM? What hypervisor? > It could be a bug there. > Yeah, it's running in KVM/QEMU on an Ubuntu 18.04 host. The only thing slightly unusual is the Kaby Lake CPU. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
On 26/09/2019 18:45, 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. Given the qcow2 image, is this in a VM? What hypervisor? It could be a bug there. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
You're right, cem. gdb and ddb show the same data. Here it is from gdb: 0x8113b30e : 0xf2 0x48 0x0f 0x38 0xf1 0xde 0xf2 0x48 0x8113b316 : 0x0f 0x38 0xf1 0xc7 0x48 0x8b 0x32 0xf2 0x8113b31e : 0x4c 0x0f 0x38 0xf1 0xde 0x48 0x8d 0x72 0x8113b326 : 0x08 0x48 0x81 0xc2 0x08 0xff 0xff 0xff 0x8113b32e : 0x4c 0x39 0xca 0x72 0xcd 0x44 0x0f 0xb6 0x8113b336 : 0xc9 0x0f 0xb6 0xfd 0x89 0xca 0xc1 0xea 0x8113b33e : 0x10 0x0f 0xb6 0xd2 0xc1 0xe9 0x18 0x42 0x8113b346 : 0x33 0x1c 0x8d 0x80 0x11 0xf9 0x81 0x33 Here are the last few console messages from before the panic: virtio_pci1: port 0xc000-0xc03f mem 0xfc098000-0xfc 098fff,0xfebf4000-0xfebf7fff irq 10 at device 6.0 on pci0 virtio_pci2: port 0xc040-0xc07f mem 0xfc099000-0xfc09 9fff,0xfebf8000-0xfebfbfff irq 11 at device 7.0 on pci0 vtblk0: on virtio_pci2 vtblk0: 34816MB (71303296 512 byte sectors) virtio_pci3: port 0xc120-0xc13f mem 0xfebfc000-0xfe bf irq 11 at device 8.0 on pci0 vtballoon0: on virtio_pci3 acpi_syscontainer0: on acpi0 acpi_syscontainer1: port 0xaf00-0xaf0b on acpi0 acpi_syscontainer2: port 0xafe0-0xafe3 on acpi0 acpi_syscontainer3: port 0xae00-0xae13 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 panic: Unregistered use of FPU in kernel On Thu, Sep 26, 2019 at 2:19 PM Conrad Meyer wrote: > This kinda just looks like ddb doesn't know how to disassemble crc32q? > Which might not be too surprising. > > Note that it also truncates the qword constant in "add" at +167/+0xa7. > That one isn't corruption; just a DDB bug. > > Can you print the faulting %rip and dump a few bytes at that address > in both ddb and gdb (assuming ddb can't disassemble crc32q)? > > Best, > Conrad > > On Thu, Sep 26, 2019 at 1:12 PM Alan Somers wrote: > > > > On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov < > kostik...@gmail.com> > > wrote: > > > > > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > > > kostik...@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. > > > > > > > Ok, here's the full stack trace: > > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 > > #2 0x804a1edb in db_dump (dummy=, > > dummy2=, dummy3=, dummy4=) > > at /usr/src/sys/ddb/db_command.c:575 > > #3 0x804a1c8f in db_command (last_cmdp=, > > cmd_table=, dopager=1) at > > /usr/src/sys/ddb/db_command.c:482 > > #4 0x804a1a04 in db_command_loop () > > at /usr/src/sy
Re: panic: Unregistered use of FPU in kernel
On Thu, Sep 26, 2019 at 02:12:21PM -0600, Alan Somers wrote: > On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov > wrote: > > > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > > kostik...@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. > > > > Ok, here's the full stack trace: > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 > #2 0x804a1edb in db_dump (dummy=, > dummy2=, dummy3=, dummy4=) > at /usr/src/sys/ddb/db_command.c:575 > #3 0x804a1c8f in db_command (last_cmdp=, > cmd_table=, dopager=1) at > /usr/src/sys/ddb/db_command.c:482 > #4 0x804a1a04 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:535 > #5 0x804a4cbf in db_trap (type=, code= out>) > at /usr/src/sys/ddb/db_main.c:252 > #6 0x80c1e55c in kdb_trap (type=3, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:692 > #7 0x811957df in trap (frame=0xfe00907e8d20) > at /usr/src/sys/amd64/amd64/trap.c:621 > #8 This is not a useful trace. It only shows the ddb part after the trap. Please show all console messages around the panic, as was requested. > > Your guess about corrupted text was prescient. Here is the disassembly > according to ddb: > https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png > And here is the disassembly of the same section according to gdb: >0x8113b2e0 : mov%rsi,%r9 >0x8113b2e3 : sub$0xff80,%r9 >0x8113b2e7 : add$0x100,%rsi >0x8113b2ee : mov%r11,%rbx >0x8113b2f1 : xor%eax,%eax >0x8113b2f3 : xor%r11d,%r11d >0x8113b2f6 : nopw %cs:0x0(%rax,%rax,1) >0x8113b300 : mov%rsi,%rdx >0x8113b303 : mov-0x100(%rsi),%rsi >0x8113b30a : mov-0x80(%rdx),%rdi >0x8113b30e : crc32q %rsi,%rbx >0x8113b314 : crc32q %rdi,%rax >0x8113b31a : mov(%rdx),%rsi >0x8113b31d : crc32q %rsi,%r11 >0x8113b323 : lea0x8(%rdx),%rsi >0x8113b327 : add$0xff08,%rdx >0x8113b32e : cmp%r9,%rdx >0x8113b331 : > jb 0x8113b300 >0x8113b333 : movzbl %cl,%r9d >0x8113b337 : movzbl %ch,%edi >0x8113b33a : mov%ecx,%edx > > Care to guess what's causing the corruption? I agree with cem that it is more likely ddb disassembler unable to handle some aspects, and that looking at hex bytes of the faulted instruction is the interesting data. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
This kinda just looks like ddb doesn't know how to disassemble crc32q? Which might not be too surprising. Note that it also truncates the qword constant in "add" at +167/+0xa7. That one isn't corruption; just a DDB bug. Can you print the faulting %rip and dump a few bytes at that address in both ddb and gdb (assuming ddb can't disassemble crc32q)? Best, Conrad On Thu, Sep 26, 2019 at 1:12 PM Alan Somers wrote: > > On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov > wrote: > > > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > > kostik...@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. > > > > Ok, here's the full stack trace: > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 > #2 0x804a1edb in db_dump (dummy=, > dummy2=, dummy3=, dummy4=) > at /usr/src/sys/ddb/db_command.c:575 > #3 0x804a1c8f in db_command (last_cmdp=, > cmd_table=, dopager=1) at > /usr/src/sys/ddb/db_command.c:482 > #4 0x804a1a04 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:535 > #5 0x804a4cbf in db_trap (type=, code= out>) > at /usr/src/sys/ddb/db_main.c:252 > #6 0x80c1e55c in kdb_trap (type=3, code=0, tf=) > at /usr/src/sys/kern/subr_kdb.c:692 > #7 0x811957df in trap (frame=0xfe00907e8d20) > at /usr/src/sys/amd64/amd64/trap.c:621 > #8 > > Your guess about corrupted text was prescient. Here is the disassembly > according to ddb: > https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png > And here is the disassembly of the same section according to gdb: >0x8113b2e0 : mov%rsi,%r9 >0x8113b2e3 : sub$0xff80,%r9 >0x8113b2e7 : add$0x100,%rsi >0x8113b2ee : mov%r11,%rbx >0x8113b2f1 : xor%eax,%eax >0x8113b2f3 : xor%r11d,%r11d >0x8113b2f6 : nopw %cs:0x0(%rax,%rax,1) >0x8113b300 : mov%rsi,%rdx >0x8113b303 : mov-0x100(%rsi),%rsi >0x8113b30a : mov-0x80(%rdx),%rdi >0x8113b30e : crc32q %rsi,%rbx >0x8113b314 : crc32q %rdi,%rax >0x8113b31a : mov(%rdx),%rsi >0x8113b31d : crc32q %rsi,%r11 >0x8113b323 : lea0x8(%rdx),%rsi >0x8113b327 : add$0xff08,%rdx >0x8113b32e : cmp%r9,%rdx >0x8113b331 : > jb 0x8113b300 >0x8113b333 : movzbl %cl,%r9d >0x8113b337 : movzbl %ch,%edi >0x8113b33a : mov%ecx,%edx > > Care to guess what's causing the corruption? > -Alan > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov wrote: > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > kostik...@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. > Ok, here's the full stack trace: #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 #2 0x804a1edb in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0x804a1c8f in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482 #4 0x804a1a04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0x804a4cbf in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #6 0x80c1e55c in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:692 #7 0x811957df in trap (frame=0xfe00907e8d20) at /usr/src/sys/amd64/amd64/trap.c:621 #8 Your guess about corrupted text was prescient. Here is the disassembly according to ddb: https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png And here is the disassembly of the same section according to gdb: 0x8113b2e0 : mov%rsi,%r9 0x8113b2e3 : sub$0xff80,%r9 0x8113b2e7 : add$0x100,%rsi 0x8113b2ee : mov%r11,%rbx 0x8113b2f1 : xor%eax,%eax 0x8113b2f3 : xor%r11d,%r11d 0x8113b2f6 : nopw %cs:0x0(%rax,%rax,1) 0x8113b300 : mov%rsi,%rdx 0x8113b303 : mov-0x100(%rsi),%rsi 0x8113b30a : mov-0x80(%rdx),%rdi 0x8113b30e : crc32q %rsi,%rbx 0x8113b314 : crc32q %rdi,%rax 0x8113b31a : mov(%rdx),%rsi 0x8113b31d : crc32q %rsi,%r11 0x8113b323 : lea0x8(%rdx),%rsi 0x8113b327 : add$0xff08,%rdx 0x8113b32e : cmp%r9,%rdx 0x8113b331 : jb 0x8113b300 0x8113b333 : movzbl %cl,%r9d 0x8113b337 : movzbl %ch,%edi 0x8113b33a : mov%ecx,%edx Care to guess what's causing the corruption? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov > 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Unregistered use of FPU in kernel
On 26.09.2019 20:02, Konstantin Belousov wrote: >> 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. *sse42*_crc32c on top of the stack says, that it USES SSE :) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: panic: Unregistered use of FPU in kernel
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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: Unregistered use of FPU in kernel
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. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
