#20090 closed defect (fixed)
Black screen on EFI VM
Reported by: | CornFlake | Owned by: | |
---|---|---|---|
Component: | EFI | Version: | VirtualBox 6.1.16 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | Linux |
Description
New laptop with Intel i5-1035G1 CPU. Attempting to boot an EFI VM results in a black screen and 100% CPU utilization, regardless of guest OS. The EFI shell doesn't come up either. Discussed in this thread: https://forums.virtualbox.org/viewtopic.php?f=7&t=100940
Attached is a copy of a blank VM with EFI enabled and its logs. I'm also attaching a copy of dmesg, top, and top+H.
Attachments (8)
Change History (46)
by , 4 years ago
by , 4 years ago
by , 4 years ago
by , 4 years ago
comment:1 by , 4 years ago
As can be seen from my posts in the forum thread, VirtualBox doesn't know several CPUID Structured Extended Feature Flags. Additionally, the vCPU is running endlessly in the midst of the (U)EFI BIOS loading (possibly somewhere near the watchdog and timer initialization, but I'm not sure about that).
by , 4 years ago
Attachment: | win10.tar.gz added |
---|
by , 4 years ago
Attachment: | win10.tar.2.gz added |
---|
by , 4 years ago
comment:2 by , 4 years ago
I ran into very similar 'black screen' behavior with an 11-th gen i7. I've attached a test VM that re-creates this issue along with a dump of /proc/cpuinfo in case that is helpful. This VM works fine on another machine with older gen i5.
comment:4 by , 3 years ago
Same here, black screen on a laptop with an 11-th gen i7 using EFI, everything works fine on a 7-th and 8-th gen i5. Host systems used are Fedora 33 and 34 (both exhibit the same behaviour), guest systems used/tested are Fedora 32,33 and 34 and Windows.
comment:5 by , 3 years ago
Hi All, I can confirm the issue. I used Dell 5510 laptop on Ubuntu 20.04 with i7-10850H - VirtualBox worked well. I moved whole system to a new Dell 5520 with i7-1185G7 - and I have the issue.
comment:6 by , 3 years ago
I also have this problem on a Dell XPS 13 with an 11th gen i7-1165G7, running Fedora 33. I also see the thread named "EMT" spinning at 100% CPU. In case it is helpful, here is a gdb backtrace of the thread:
#0 0x00007fe66d55f5db in ioctl () from /lib64/libc.so.6 #1 0x00007fe66d35e4ed in suplibOsIOCtlFast (pThis=<optimized out>, uFunction=<optimized out>, idCpu=<optimized out>) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/HostDrivers/Support/linux/SUPLib-linux.cpp:212 #2 0x00007fe64880e8d9 in VMMR3HmRunGC (pVM=0x7fe64806e000, pVCpu=0x7fe648059000) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/VMM/VMMR3/VMM.cpp:1100 #3 0x00007fe6487a5eb4 in emR3HmExecute (pVM=0x7fe64806e000, pVCpu=0x7fe648059000, pfFFDone=0x7fe6250c9d57) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/VMM/VMMR3/EMHM.cpp:418 #4 0x00007fe6487a3c3e in EMR3ExecuteVM (pVM=<optimized out>, pVCpu=<optimized out>) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/VMM/VMMR3/EM.cpp:2657 #5 0x00007fe648806990 in vmR3EmulationThreadWithId (hThreadSelf=<optimized out>, pUVCpu=0x7fe6250d16a0, idCpu=0) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/VMM/VMMR3/VMEmt.cpp:237 #6 0x00007fe66d29b7d4 in rtThreadMain (pThread=0x7fe6140062f0, NativeThread=<optimized out>, pszThreadName=<optimized out>) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/Runtime/common/misc/thread.cpp:727 #7 0x00007fe66d3534ee in rtThreadNativeMain (pvArgs=0x7fe6140062f0) at /usr/src/debug/VirtualBox-6.1.18-1.fc33.x86_64/src/VBox/Runtime/r3/posix/thread-posix.cpp:384 #8 0x00007fe66d6423f9 in start_thread () from /lib64/libpthread.so.0 #9 0x00007fe66d568b53 in clone () from /lib64/libc.so.6
I'm happy to collect any other information that might be helpful.
comment:7 by , 3 years ago
A further possibly interesting piece of information: I booted an EFI-using VM on a host machine with an i7-9700K, then saved its state. I copied all the files across to the machine with the i7-1165G7 and the VM happily resumed and appeared to be working fine. That suggests that the problem is just with the EFI boot, and that if the VM got past that stage, it would work for everything else.
comment:10 by , 3 years ago
virtualbox-6.1_6.1.20-143896_Ubuntu_eoan_amd64.deb does not solve this issue for me too.
comment:11 by , 3 years ago
VirtualBox 6.1.22 does not solve this issue as well. Guess this one is really hard to crack for some reason.
comment:12 by , 3 years ago
Any news on this one? The bug report is open for 5 months now. I am forced to use an old laptop now for VirtualBox. I am really thinking about ditching VB and switching to VMware-Player, Gnome Boxes or Virt-Manager.
comment:14 by , 3 years ago
I'll make an educated guess:
Please reboot your Linux host, providing the kernel parameter split_lock_detect=off. Does the issue still occur?
comment:15 by , 3 years ago
I was having the same issue, and the change in kernel parameter proposed by fth0 solved it.
P.S.: Before trying this, I've tried to use the developer snapshot 6.1.97-142300, it solve the EFI issue, but on my machine created a lot of new issues.
My system is:
Computer: Acer Aspire A515-55
S.O.: Fedora 34 Workstation
Processor: Intel® Core™ i5-1035G1 CPU @ 1.00GHz × 8
Graphics: Mesa Intel® UHD Graphics (ICL GT1)
Kernel: 5.12.8
VirtualBox Version: 6.1.22
comment:16 by , 3 years ago
An initial test suggests that split_lock_detect=off also solves the issue for me on a Dell XPS-13 with 11th gen i7-1165G7 running Fedora 34. Thanks for the suggestion fth0!
comment:17 by , 3 years ago
split_lock_detect=off didn't fix the issue on my Dell XPS 13 9310 (i7-1185G7)
Some system outputs
# uname -a Linux foo 5.13.0-rc4-seblu #1 SMP PREEMPT Mon May 31 03:25:45 CEST 2021 x86_64 GNU/Linux # cat /proc/cmdline i915.enable_psr=0 split_lock_detect=off quiet # dmesg|tail [ 629.781305] vboxdrv: 000000003d4de0d3 VBoxEhciR0.r0 [ 629.782757] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0) [ 629.801848] device vboxnet0 entered promiscuous mode [ 633.598424] device vboxnet0 left promiscuous mode [ 633.709048] !!Assertion Failed!! Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf Location : /build/virtualbox/src/VirtualBox-6.1.22/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(575) int PDMCritSectLeave(PPDMCRITSECT) [ 633.709060] ffffbbd4c5d71000 <R3_STRING>: ffffffffffffffff != 00007ff04c146640; cLockers=-1 cNestings=1 [ 633.729645] vboxnetflt: 0 out of 6 packets were not sent (directed to host)
Vbox logs
00:00:04.510348 VUSB: Detached 'HidMouse' from port 1 on RootHub#1 00:00:04.510410 VUSB: Detached 'HidMouse' from port 2 on RootHub#1 00:00:04.510795 00:00:04.510795 !!R0-Assertion Failed!! 00:00:04.510796 Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf 00:00:04.510796 Location : /build/virtualbox/src/VirtualBox-6.1.22/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(575) int PDMCritSectLeave(PPDMCRITSECT) 00:00:04.510800 ffffbbd4c78fd000 <R3_STRING>: ffffffffffffffff != 00007f304c130640; cLockers=-1 cNestings=1 00:00:04.566137 GIM: KVM: Resetting MSRs 00:00:04.567177 Changing the VM state from 'DESTROYING' to 'TERMINATED' 00:00:04.571336 Console: Machine state changed to 'PoweredOff' 00:00:05.093529 GUI: Passing request to close Runtime UI from machine-logic to UI session. 00:00:05.093926 GUI: Aborting startup due to invalid machine state detected: 1
comment:18 by , 3 years ago
I can also confirm that "split_lock_detect=off" solved the issue from my original post. Thanks fth0!
follow-up: 20 comment:19 by , 3 years ago
I have a much older CPU (i7-5930K) so split_lock_detect=off
does not apply to mine (and does not fix this issue). I am getting the same assertion error in kernel log for EFI-based VMs.
I am on Linux 5.13.0 (Gentoo) with VirtualBox 6.1.22. Everything is up-to-date.
$ uname -a Linux limelight 5.13.0-gentoo-limelight #2 SMP Wed Jun 30 01:24:37 EDT 2021 x86_64 Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz GenuineIntel GNU/Linux tatsh@limelight ~ $ journalctl -n 15 -k -- Journal begins at Wed 2021-01-20 07:08:58 EST, ends at Wed 2021-06-30 01:54:56 EDT. -- Jun 30 01:37:56 limelight kernel: !!Assertion Failed!! Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf Location : /var/tmp/portage/app-emulation/virtualbox-6.1.22/work/VirtualBox-6.1.22/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(575) int PDMCritSectLe> Jun 30 01:37:56 limelight kernel: ffffb28e4cd6d000 <R3_STRING>: ffffffffffffffff != 00007f25141dc640; cLockers=-1 cNestings=1 Jun 30 01:38:05 limelight kernel: vboxdrv: 00000000c31ac7c3 VMMR0.r0 Jun 30 01:38:05 limelight kernel: vboxdrv: 00000000e8839b3f VBoxDDR0.r0 Jun 30 01:38:05 limelight kernel: VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0) Jun 30 01:38:06 limelight kernel: !!Assertion Failed!! Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf Location : /var/tmp/portage/app-emulation/virtualbox-6.1.22/work/VirtualBox-6.1.22/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(575) int PDMCritSectLe> Jun 30 01:38:06 limelight kernel: ffffb28e45cd0000 <R3_STRING>: ffffffffffffffff != 00007fe7ac199640; cLockers=-1 cNestings=1 Jun 30 01:38:56 limelight kernel: vboxdrv: 00000000b726513d VMMR0.r0 Jun 30 01:38:56 limelight kernel: vboxdrv: 0000000038008452 VBoxDDR0.r0 Jun 30 01:38:56 limelight kernel: vboxdrv: 00000000e77c1821 VBoxEhciR0.r0 Jun 30 01:38:56 limelight kernel: VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0) Jun 30 01:39:19 limelight kernel: vboxdrv: 0000000046693f48 VMMR0.r0 Jun 30 01:39:19 limelight kernel: vboxdrv: 00000000d91ea0cd VBoxDDR0.r0 Jun 30 01:39:19 limelight kernel: vboxdrv: 00000000dc26d0ad VBoxEhciR0.r0 Jun 30 01:39:19 limelight kernel: VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
follow-up: 24 comment:20 by , 3 years ago
Replying to Tatsh:
I have a much older CPU (i7-5930K) so
split_lock_detect=off
does not apply to mine (and does not fix this issue). I am getting the same assertion error in kernel log for EFI-based VMs.
I agree that you and seblu get the same assertion failure, but I don't see it in the dmesg.log of CornFlake. So it is possible that you both are having a different issue.
comment:22 by , 3 years ago
Replying to Razorback:
This patch didn't help :(
Are you posting to the correct topic (I don't see any relation)?
comment:23 by , 3 years ago
I've just had the same
!!Assertion Failed!! Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf Location : /var/tmp/portage/app-emulation/virtualbox-6.1.22/work/VirtualBox-6.1.22/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(575) int PDMCritSectLe> Jun 30 01:38:06 limelight kernel: ffffb28e45cd0000 <R3_STRING>: ffffffffffffffff != 00007fe7ac199640; cLockers=-1 cNestings=1
and thought that is it
follow-ups: 25 28 comment:24 by , 3 years ago
Replying to fth0:
Replying to Tatsh:
I have a much older CPU (i7-5930K) so
split_lock_detect=off
does not apply to mine (and does not fix this issue). I am getting the same assertion error in kernel log for EFI-based VMs.I agree that you and seblu get the same assertion failure, but I don't see it in the dmesg.log of CornFlake. So it is possible that you both are having a different issue.
What information can I provide to get further assistance?
comment:25 by , 3 years ago
Replying to Tatsh:
Replying to fth0:
Replying to Tatsh:
I have a much older CPU (i7-5930K) so
split_lock_detect=off
does not apply to mine (and does not fix this issue). I am getting the same assertion error in kernel log for EFI-based VMs.I agree that you and seblu get the same assertion failure, but I don't see it in the dmesg.log of CornFlake. So it is possible that you both are having a different issue.
What information can I provide to get further assistance?
I'd suggest that you create your own bug ticket with a title and a description more specific to your problem (e.g. mentioning the assertion regarding NativeThreadOwner), and hope for a VirtualBox developer getting interested.
comment:26 by , 3 years ago
fth0 Kernel 5.13 was marked as bad by Gentoo due to this issue: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff4b2b4014cbffb3d32b22629252f4dc8616b0fe
Does it seem related?
I downgraded back to 5.12 so now VirtualBox works fine. I can test 5.13 when the next stable release comes out.
comment:28 by , 3 years ago
Replying to Tatsh:
What information can I provide to get further assistance?
Can you provide a VBox.log file from a failing VM run and the corresponding part of the kernel log?
comment:29 by , 3 years ago
Please try one of the VirtualBox test builds 6.1.23r145550 or later, which should solve the issue of the OP and others, but not the issues with Linux kernel 5.13, and report back. TIA.
follow-up: 32 comment:30 by , 3 years ago
The problem with 5.13 is the addition and enabling of CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. Adding randomize_kstack_offset=0
to the linux kernel command line should disable this and avoid the VERR_INVALID_STATE guru.
comment:31 by , 3 years ago
Please try the VirtualBox test builds 6.1.23r145697 (or newer) that are supposed to fix VirtualBox issues on hosts with Linux kernel 5.13, and report back. TIA.
follow-up: 33 comment:32 by , 3 years ago
Replying to bird:
The problem with 5.13 is the addition and enabling of CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT. Adding
randomize_kstack_offset=0
to the linux kernel command line should disable this and avoid the VERR_INVALID_STATE guru.
This fixed my issue. I rebuilt my kernel with CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=n and now VirtualBox EFI machines start fine.
Replying to fth0:
Please try the VirtualBox test builds 6.1.23r145697 (or newer) that are supposed to fix VirtualBox issues on hosts with Linux kernel 5.13, and report back. TIA.
Happy to test but are these new builds supposed to fix for users using CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
on 5.13?
comment:33 by , 3 years ago
Replying to Tatsh:
Replying to fth0:
Please try the VirtualBox test builds 6.1.23r145697 (or newer) that are supposed to fix VirtualBox issues on hosts with Linux kernel 5.13, and report back. TIA.
Happy to test but are these new builds supposed to fix for users using
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
on 5.13?
The new test builds are supposed to make adding randomize_kstack_offset=0 to the linux kernel command line unnecessary.
comment:34 by , 3 years ago
To state it clearly: yes, 6.1.23r145697 (or newer) works with Linux 5.13 with default config (CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y ), not needing any kernel command line tweaking.
comment:35 by , 3 years ago
I updated to 6.1.24 and re-enabled CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT
and everything works like normal.
comment:36 by , 3 years ago
<https://www.virtualbox.org/wiki/Changelog-6.1#v24> (2021-07-20) references this bug:
EFI: Stability improvements (bug #20090)
comment:37 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:38 by , 4 months ago
I'm looking for a way to fix these errors slope but haven't found any yet, hope everyone can give me some suggestions.
Blank VM with EFI enabled