Date: Wed, 10 Aug 2016 19:40:31 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@freebsd.org, jhb@freebsd.org Subject: Re: kernel panic caused by virtualbox(?) Message-ID: <fac82552-3640-4662-12fa-048b0c26dfb2@FreeBSD.org> In-Reply-To: <20160809091230.GQ83214@kib.kiev.ua> References: <20160808183743.GL83214@kib.kiev.ua> <201608082344.u78NiK1V030408@gw.catspoiler.org> <20160809091230.GQ83214@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS Content-Type: multipart/mixed; boundary="0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg" From: Jung-uk Kim <jkim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@freebsd.org, jhb@freebsd.org Message-ID: <fac82552-3640-4662-12fa-048b0c26dfb2@FreeBSD.org> Subject: Re: kernel panic caused by virtualbox(?) References: <20160808183743.GL83214@kib.kiev.ua> <201608082344.u78NiK1V030408@gw.catspoiler.org> <20160809091230.GQ83214@kib.kiev.ua> In-Reply-To: <20160809091230.GQ83214@kib.kiev.ua> --0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/09/16 05:12 AM, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >> On 8 Aug, Konstantin Belousov wrote: >>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >>>>> Reposted to -current to get some more eyes on this ... >>>>> >>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtua= lbox. >>>>> The host is: >>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >>>>> The virtualbox version is: >>>>> virtualbox-ose-5.0.26 >>>>> virtualbox-ose-kmod-5.0.26_1 >>>>> >>>>> The panic message is: >>>>> >>>>> panic: Unregistered use of FPU in kernel >>>>> cpuid =3D 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff= e085a55d030 >>>>> vpanic() at vpanic+0x182/frame 0xfffffe085a55d0b0 >>>>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe085a55d120 >>>>> trap() at trap+0x7ae/frame 0xfffffe085a55d330 >>>>> calltrap() at calltrap+0x8/frame 0xfffffe085a55d330 >>>>> --- trap 0x16, rip =3D 0xffffffff827dd3a9, rsp =3D 0xfffffe085a55d4= 08, rbp =3D 0xfffffe085a55d430 --- >>>>> g_pLogger() at 0xffffffff827dd3a9/frame 0xfffffe085a55d430 >>>>> g_pLogger() at 0xffffffff8274e5c7/frame 0x3 >>>>> KDB: enter: panic >>>>> >>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox= is >>>>> the trigger. >>>>> >>>>> There are no symbols for the virtualbox kmods, possibly because I >>>>> installed them as an upgrade using packages (built with the same so= urce >>>>> tree version) instead of by using PORTS_MODULES in make.conf, so po= rts >>>>> kgdb didn't have anything useful to say about what happened before = the >>>>> trap. >>>>> >>>>> This panic is very repeatable. I just got another one when startin= g the >>>>> same VM., but this time the two calls before the trap were >>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... >>>>> >>>>> I don't see this with a Windows 7 VM. >>>>> >>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-ss= e >>>>> -msoft-float -mno-aes -mno-avx >>> Your disassemble listed fxrstor instruction that failing, or did I >>> mis-remembered ? This is most likely some context switch code, either= >>> by virtual machine or erronously executed guest code. It is not a >>> spontaneous use of FPU, but more likely something different. Can you >>> confirm ? >>> >>> In either case, I do not remember any KBI changes around PCB layout o= r >>> fpu_enter() KPI recently. >>> >>>> >>>> I suspect head packages are quite likely built against the a "wrong"= KBI >>>> and are too fragile to use for kmods vs compiling from ports. :-/ I= would >>>> try a built-from-ports kmod to see if the panics go away. >>> >>> FWIW, I will commit the following change shortly. Since third-party >>> modules break the invariant, either due to bugs (ndis wrappers) or >>> possibly due to KBI breakage, it is worth to have the detection enabl= ed >>> for production kernels. >> >> Interesting ... I tried running virtualbox on recent 10.3-STABLE with = a >> GENERIC kernel and the guest seemed to operate properly. Then I enabl= ed >> INVARIANTS and got the panic. I suspect that is why nobody has stumbl= ed >> across this before. >> > This is yet another reason to promote KASSERT to the full panic. > I expect that the vbox source lacks fpu_kern_enter() calls around the > FPU state restoration. Unfortunately, the code is in MI source as it is unnecessary for supported OSes (read: FreeBSD is not supported) and it's not easy to inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( Jung-uk Kim --0mSLbSBcI8Q4u5xdTcVVRBScbAuqUDecg-- --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXq7tvAAoJEHyflib82/FGUIIH/3Iwm/g/qCesL+GvokRPPKBV qyW3vvcNKggNIVovOkQgMkK62LRHEOWxor3CBAJIJ2pvt9XvaQVnz/u/NdcR5eOk 22/9rBZRn50nKM4zfQ04kMPo5EE3gS+dQXz/SK7S8AQogsav/DNMBOP84iYPbSmY KN42i/7jek9tmqVkqYCTUh1IxDCHns3b30TUPDQP/1A6eRxinapadxOUaKF90r3I uYILXhfZaumHqrA1njY20HR5AhFBmL1KZ1LM4vfarMzZoxtHSG840qTKepdPlSNB H9Cpgq5iepvwkuXLd0C1H2+x8fqN/cTeNm+IV3LxEuVuiC9HZQGco5R7phyP1Sg= =K4oD -----END PGP SIGNATURE----- --ccdJQC0AGf00xMkxKCAAkJtOsNtXJ4wpS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fac82552-3640-4662-12fa-048b0c26dfb2>