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: Kernel panic after rebuilding CURRENT
Just a me too, for me it is a standard FreeBSD running on virtualbox. regards, Johan Op wo 25 sep. 2019 om 17:30 schreef mms.vanbreukelin...@gmail.com < mms.vanbreukelin...@gmail.com>: > Had verbose on and got the following kernel error on 290: > taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu > Looked for device tqg, isn't available in a slightly changing GENERIC > custom. I know what this personally means to me, incompatibility and a > lack of social integration, but what's the reason for BSD telling me: > "thank you, that's it!" I have LOCK_PROFILING as option for building, but > this had nothing to do with that kinda problem. > Reversion from this morning, as a lack of Inet at the moment, I had to > 'svn up' from within Linux with ufs write enabled and gave root to the > rescue CD for fsck'ing the /dev/ada0p7. The hashkey terror stops and when > unmounted without flags -fl on arch. They're doing well together simple > because if unification purpose against monopoly. > Had to rebuild without SMP, so virtualization is problematic. #ing the > ule_scheduler shouldn't be "unticked", as this causes severe compile > errors. > I think she just wants a backward development at this age, nostalgia > electronica should be a study tribe on universities like history in > school! Anyone able to get 2nd CPU up again? > ___ > 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"
