[vbox-dev] Linux-4.12-rc1 and rc2 not working as vbox guest ?
Hans de Goede
hdegoede at redhat.com
Mon May 29 14:22:09 GMT 2017
Hi,
On 29-05-17 15:12, Frank Mehnert wrote:
> Hi Hans,
>
> On Montag, 29. Mai 2017 13:27:33 CEST Hans de Goede wrote:
>> On 29-05-17 12:23, Hans de Goede wrote:
>>> On 25-05-17 11:57, Hans de Goede wrote:
>>>> 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.
>
> sorry, but did you also try to boot the kernel from Torvald's latest master
> without any VBox-related kernel modules added? I'm not sure about that when
> reading your instructions.
>
> It is known that the 5.1.22 VirtualBox Guest Additions kernel modules do not
> compile against Linux 4.12-rc, therefore I assume you only added the vboxvideo
> stuff to your kernel but you didn't use any vboxguest code, is that correct?
>
>>>> 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.
>
> This guest warning is expected on certain CPUs. VirtualBox does not expose the
> whole XSAVE state to the guest and that causes gaps which Linux warns about.
> This is a warning, not a fatal error.
>
> I get the exact same warning if I boot a Fedora 25 guest on VBox 5.1.22 on a
> host with Linux 4.11 running on a Skylake processor.
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).
>>> 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 ?
>
> Very unlikely. We are using gcc 7.1 on some hosts as well.
Seems you're right downgrading gcc did not help, downgrading
binutils also did not help.
So on a hunch I removed the ssd from the working F25 Ivy Bridge
test-machine boot it in an USB enclosure and booted my main
Sky Lake workstation from it and now the working F25 4.10.5 x86_64
host + F26 4.12-rc2 x86_64 guest from that ssd of all a sudden stops
booting.
I also tried booting a Sky Lake laptop from the ssd same symptons,
booting the Ivy Bridge test machine from the ssd in the USB-enclosure
to rule out the USb enclosure playing a role gives me a working vm
again.
TL;DR: It seems that the 4.12 kernel will not boot as a guest on
Sky Lake based hosts.
>> 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.
>
> The XSAVE consistency problem and the guest being unable to boot are most
> likely two different problems.
I'm not sure, this message only shows up on Sky Lake based hosts and now with
4.12 based guests only Skylake based hosts no longer boot ?
>> 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:
Regards,
Hans
More information about the vbox-dev
mailing list