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

Hans de Goede hdegoede at redhat.com
Mon May 29 11:27:33 GMT 2017


Hi,

On 29-05-17 12:23, Hans de Goede wrote:
> Hi,
> 
> On 25-05-17 11:57, Hans de Goede wrote:
>> Hi,
>>
>> On 24-05-17 18:13, Michael Thayer wrote:
>>> 24.05.2017 16:02, Michael Thayer wrote:
>>>> 24.05.2017 15:16, Hans de Goede wrote:
>>>> [...]
>>>>> I cannot get a Fedora 26 guest to boot with either distro-provided or
>>>>> self-built 4.12-rc# kernels, the distro-provided 4.11 kernel works fine.
>>>>>
>>>>> After selecting a 4.12# kernel in the grub menu the vm shows an empty
>>>>> text screen with a cursor in the top left corner and then just hangs.
>>>>>
>>>>> Anyone know how to fix this ? This is with VirtualBox 5.1.22 on a Fedora
>>>>> host.
>>>>
>>>> Hello Hans,
>>>>
>>>> Downloading F26 alpha now to take a look.  Did you try a serial console
>>>> redirected to a host file to get early boot messages?
>>>>
>>>> And I am back at work now and hope look at your patches soon!
>>>
>>> Just tried 4.12-rc1 from Rawhide (is that right?)  It boots fine here, Ubuntu 17.04 host.  Could it be something in your virtual machine configuration or your host?  A log file for the machine might tell us more.
>>
>> Ok, so here is what I did:
>>
>> 1) Download F26 nightly compose live iso
>> 2) Start virtualbox 5.1.20 from rpmfusion pkgs, create new vm, type "Fedora 64 bit"
>> 3) Use vm for a while to test vboxvideo stuff
>> 4) Manually install a kernel build from Torvald's latest master with the
>> intend to start working on putting the vboxvideo code under drivers/staging
>> 5) Hmm, does not boot, lets try a Fedora built 4.12-rc# kernel from rawhide
>> 6) Hmm still does not boot, remove 5.1.20 pkgs from rpmfusion, install
>>     5.1.22 from virtualbox.org
>> 7) Still does not boot (and the 4.11 kernel does still boot) time to mail
>>     this list.
>>
>> I've just tried installing and booting kernel-4.12.0-0.rc1.git0.1.fc27.x86_64 and
>> still no luck. I guess I can try re-recreating the vm, might that help ?
> 
> So this morning again I've tried to get my vm to boot with a 4.12 kernel,
> no luck. One thing I did notice is that the 4.11 kernel which does work
> gives this error very early on during boot:
> 
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:596 fpu__init_system_xstate+0x48f/0x870
> [    0.000000] XSAVE consistency problem, dumping leaves
> ...
> 
> Which I guess is not normal. Could this be a problem with my host ?
> My host is a Fedora 26 install, running 4.11.3, I've tried downgrading
> the host kernel to 4.10.7 but that does not help.
> 
> Maybe something with Fedora 26's gcc version ? :
> 
> [hans at shalem ~]$ rpm -q gcc
> gcc-7.1.1-1.fc26.x86_64
> 
> Causing a miscompile of the host drivers ?

Ok, this is indeed a host problem, I copied the vm to a Fedora 25 64 bit
host with a 4.10.5 kernel and there it works fine, including the 4.11
kernel not showing the "XSAVE consistency problem" message, and the 4.12
kernel working just fine.

Here are more complete guest kernel logs of the "XSAVE consistency problem"
when using A Fedora 26 64 bit host with kernel 4.10 and a 4.11 guest kernel:

[    0.000000] Linux version 4.11.0-2.fc26.x86_64 (mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 7.1.1 20170503 (Red Hat 7.1.1-1) (GCC) ) #1 SMP Tue May 9 15:24:49 UTC 2017
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-2.fc26.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:596 fpu__init_system_xstate+0x48f/0x870
[    0.000000] XSAVE consistency problem, dumping leaves
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-2.fc26.x86_64 #1
[    0.000000] Call Trace:
[    0.000000]  dump_stack+0x63/0x84
[    0.000000]  __warn+0xcb/0xf0
[    0.000000]  warn_slowpath_fmt+0x5a/0x80
[    0.000000]  ? xfeature_size+0x56/0x74
[    0.000000]  fpu__init_system_xstate+0x48f/0x870
[    0.000000]  ? get_cpu_cap+0x2a3/0x370
[    0.000000]  ? msr_clear_bit+0x3a/0xa0
[    0.000000]  ? 0xffffffff91000000
[    0.000000]  fpu__init_system+0x1e1/0x208
[    0.000000]  early_cpu_init+0x102/0x104
[    0.000000]  setup_arch+0xba/0xcf3
[    0.000000]  ? printk+0x52/0x6e
[    0.000000]  ? early_idt_handler_array+0x120/0x120
[    0.000000]  start_kernel+0xb2/0x47b
[    0.000000]  ? early_idt_handler_array+0x120/0x120
[    0.000000]  x86_64_start_reservations+0x24/0x26
[    0.000000]  x86_64_start_kernel+0x13c/0x15f
[    0.000000]  start_cpu+0x14/0x14
[    0.000000] ---[ end trace 9d5a61c263f77bce ]---
[    0.000000] CPUID[0d, 00]: eax=00000007 ebx=00000440 ecx=00000440 edx=00000000
[    0.000000] CPUID[0d, 01]: eax=00000000 ebx=000003c0 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 02]: eax=00000100 ebx=00000240 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 03]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 04]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 05]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 06]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 07]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 08]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 09]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0a]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0b]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0c]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0d]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0e]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 0f]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 10]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 11]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 12]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] CPUID[0d, 13]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 1088 bytes, using 'standard' format.
[    0.000000] e820: BIOS-provided physical RAM map:

I think that fixing this guest oops stands a good chance of also making
the 4.12 kernel boot as guest on a F26 host.

Next step is to downgrade gcc on my F26 machine to the F25 version and see if
that fixes things on F26. I've rebuild the host modules on F26 with the
current gcc version redirecting stderr to catch any compiler warnings which
might be helpful, but no such luck, the only thing I got was:

/usr/share/virtualbox/src/vboxhost/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: .fixup: unexpected end of section

Which I'm seeing when building on Fedora 25 too.

Regards,

Hans





More information about the vbox-dev mailing list