[vbox-dev] Linux-4.12-rc1 and rc2 not working as vbox guest ?

Hans de Goede hdegoede at redhat.com
Thu Jun 1 12:22:29 GMT 2017


On 01-06-17 14:08, Frank Mehnert wrote:
> On Dienstag, 30. Mai 2017 09:14:31 CEST Hans de Goede wrote:
>> On 29-05-17 17:28, Frank Mehnert wrote:
>>> On Montag, 29. Mai 2017 16:58:28 CEST Frank Mehnert wrote:
>>>> Hi Hans,
>>>> On Montag, 29. Mai 2017 16:22:09 CEST Hans de Goede wrote:
>>>>> [...]
>>>>> Ok, can you try install a 4.12 kernel, e.g.:
>>>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=892258
>>>>> Download kernel-core... and kernel-modules... and then do
>>>>> rpm -ivh kernel*.rpm
>>>>> as root from a dir with the 2 downloaded files and boot
>>>>> that on that skylake host (see below).
>>>> thanks, your investigation was very helpful. Now I'm able to reproduce the
>>>> problem with Fedora 25 with a 4.12-rc kernel on a Skylake host.
>>> adding 'noxsave' to the kernel command line is a workaround.
>> Yes that works, thank you.
> we did a bit more debugging. It really looks like this is a kernel bug. It
> looks like the kernel wants to warn early about
>    XSTATE_WARN_ON(paranoid_xstate_size != fpu_kernel_xstate_size);
> (arch/x86/kernel/fpu/xstate.c:596)
> but for some reason this warning becomes a panic and, even worse, no text
> is displayed at all. The kernel is finally waiting in hlt. Same problem with
> rc3 (using the 4.12.0-0.rc3.git1.1.fc27.x86_64 packages).
> Adding 'noxsave' is a workaround because it prevents the kernel from using
> xsave at all.
> Again, this is not a VirtualBox bug although this panic will probably not
> happen on real hardware.

I strongly disagree with this not being a VirtualBox bug, I do agree
that the regression from it being an oops to it hanging the kernel at
boot is a kernel bug, can you please file a bug for this upstream and
then provide me a link ? I'm asking you to file a bug as I expect you
to be able to explain things better then me / provide more details:


(creating an account only requires an email address no other
info is needed).

No as for the disagree-ing with this not being a VirtualBox bug,
even with 4.11 the oops is a problem and is IMHO a VirtualBox bug,
I was sorta surprised when you said earlier in this thread that this
is normal and can be ignored. Oopses are never normal and should never
be ignored. Fedora / RHEL users will get a notification that the kernel
has hit a bug as soon as they login because of the oops, and oopses
are being actively tracked for people who opt-in to reporting crashes
to our backtrace server:


Now maybe this really is 2 kernel bugs, 1. The oops turning into a
hang with 4.12 and 2. The oops happening at all, but an oops is never
normal and really must be fixed. In case you believe that the oops
happening at all is also a kernel bug please file a bug for that
too and cross-reference the 2.



More information about the vbox-dev mailing list