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@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
([email protected]) (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
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
