Black screen with kernel 6.10.6

Hi,

for many years, I have a Fedora running as a VM. Beginning with kernel 6.10.4, I have the issue that after a boot, the screen just turns black. I can’t see or do anything. The issue also exists with kernel 6.10.6.

I am still able to boot into kernel 6.9.11. When running this (old) kernel, I also collected some system details for the report, see below.

I have seen similar bug reports with older versions of Fedora and NVIDIA drivers, but I don’t have an NVIDIA card.

Is there anything more I can provide?

System Details Report


Report details

  • Date generated: 2024-09-04 21:36:48

Hardware Information:

  • Hardware Model: VMware, Inc. VMware Virtual Platform
  • Memory: 1.9 GiB
  • Processor: Intel® Core™ i5-7500 × 2
  • Graphics: SVGA3D; build: RELEASE; LLVM;
  • Disk Capacity: 53.7 GB

Software Information:

  • Firmware Version: 6.00
  • OS Name: Fedora Linux 40 (Workstation Edition)
  • OS Build: (null)
  • OS Type: 64-bit
  • GNOME Version: 46
  • Windowing System: Wayland
  • Kernel Version: Linux 6.9.11-200.fc40.x86_64

I’m having this same issue with Fedora Server aarch64 on VMware (Fusion) with kernel 6.10.6. I’m booting to multi-user mode and the console login never appears. The logs seem to indicate that the terminal font fails to load. The 6.9 kernel that I still have installed boots fine.

Update:

After a bit more research, I find that enabling 3D acceleration for the VMware video adapter seems to make the 6.10 kernel boot properly.

Do you mean the setting in the screenshot? That’s already enabled for me.

That’s the VMware Workstation equivalent of the setting I used for VMware Fusion. I haven’t tried this on a PC I’m running with Workstation 17.

On further testing, I find that using a Fedora 40 server VM with the 6.10.6 and .7 kernels on VMware products (including VMware Workstation on Linux) that are using the vmwgfx VMware SVGA 3D virtual video adapter will result in a black screen on the system console if the VM is not configured to enable 3D acceleration. No login from the console is possible, although SSH access seems to work if you’ve configured it. This is a regression over kernel versions 6.9 and earlier.

I found this happening with Debian “sid” development releases running newer 6.10 kernels, so I don’t think this is Fedora specific.

Enabling 3D acceleration in the VMware Workstation’s video preferences will allow the VM to run normally - with one exception that I found…

If the host Fedora system is running with the nouveau video driver, VMware Workstation won’t recognize the host as having a supported GL 3D graphics accelerator – so checking the 3D acceleration box in the VM’s properties won’t work. It can be made to work, however, by adding the following to the .vmx file for the VMware VM:

mks.gl.allowUnsupportedDrivers = "TRUE"

This appears to be a VMWare issue and the workaround needed to bypass the problem.

I do not believe anyone has mentioned similar behavior when using either VirtualBox or QEMU VMs

It definitely is an issue with running on a VMware hypervisor, but it’s not clear where exactly the problem lies. The only thing I can say is that the issue just started rearing its ugly head after the update to the 6.10 kernel. That indicates to me that something changed in these newer kernels that has now created an incompatibility with the VMware virtual gpu driver that’s present in (and distributed as part of) the Linux kernel.

What’s even more interesting is that rebooting the VM with an older 6.9 kernel on the same Fedora installation works and does not require 3D acceleration to be turned on by the VM configuration.

I suspect that VirtualBox or QEMU don’t see the issue as their virtual graphics adapter drivers are not the same as the vmwgfx driver.

1 Like

More investigation on F40 aarch64.

6.10.3 works. Starting in 6.10.6, errors get thrown when trying to switch to the color frame buffer device boot if 3D is not enabled:

Sep 06 07:04:07 af40s-vm kernel: [drm] Initialized vmwgfx 2.20.0 20211206 for 0000:00:0f.0 on minor 0
Sep 06 07:04:07 af40s-vm kernel: Console: switching to colour frame buffer device 160x50
Sep 06 07:04:07 af40s-vm kernel: ------------[ cut here ]------------
Sep 06 07:04:07 af40s-vm kernel: Command buffer error.
Sep 06 07:04:07 af40s-vm kernel: WARNING: CPU: 0 PID: 535 at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:399 vmw_cmdbuf_ctx_process+0x264/0x278 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel: Modules linked in: nvme crct10dif_ce polyval_ce vmwgfx(+) polyval_generic nvme_core ghash_ce sha3_ce sha512_ce sha512_arm64 nvme_auth drm_t>
Sep 06 07:04:07 af40s-vm kernel: CPU: 0 PID: 535 Comm: irq/60-vmwgfx Not tainted 6.10.6-200.fc40.aarch64 #1
Sep 06 07:04:07 af40s-vm kernel: Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024
Sep 06 07:04:07 af40s-vm kernel: pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
Sep 06 07:04:07 af40s-vm kernel: pc : vmw_cmdbuf_ctx_process+0x264/0x278 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel: lr : vmw_cmdbuf_ctx_process+0x264/0x278 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel: sp : ffff8000845ebcb0
Sep 06 07:04:07 af40s-vm kernel: x29: ffff8000845ebcb0 x28: ffff000088c5ab18 x27: 0000000000000003
Sep 06 07:04:07 af40s-vm kernel: x26: dead000000000122 x25: ffff0000819a7e50 x24: dead000000000100
Sep 06 07:04:07 af40s-vm kernel: x23: ffff0000819a7c00 x22: ffff0000819a7c98 x21: ffff0000819a7c88
Sep 06 07:04:07 af40s-vm kernel: x20: ffff000088c5af00 x19: ffff000088c5ab00 x18: 0000000000000014
Sep 06 07:04:07 af40s-vm kernel: x17: 00000000ed564099 x16: 00000000b9b860c6 x15: 000000007f5dbc84
Sep 06 07:04:07 af40s-vm kernel: x14: 0000000000000001 x13: 0a2e726f72726520 x12: 7265666675622064
Sep 06 07:04:07 af40s-vm kernel: x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : ffff800080241d74
Sep 06 07:04:07 af40s-vm kernel: x8 : ffff8000845ebcb0 x7 : 0000000000000001 x6 : 0000000000000001
Sep 06 07:04:07 af40s-vm kernel: x5 : ffff0000ff503fc8 x4 : 0000000000000000 x3 : ffff80007cdc5000
Sep 06 07:04:07 af40s-vm kernel: x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008a4c4900
Sep 06 07:04:07 af40s-vm kernel: Call trace:
Sep 06 07:04:07 af40s-vm kernel:  vmw_cmdbuf_ctx_process+0x264/0x278 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel:  vmw_cmdbuf_man_process+0x6c/0x120 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel:  vmw_cmdbuf_irqthread+0x30/0x50 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel:  vmw_thread_fn+0x84/0xf0 [vmwgfx]
Sep 06 07:04:07 af40s-vm kernel:  irq_thread_fn+0x34/0xb8
Sep 06 07:04:07 af40s-vm kernel:  irq_thread+0x15c/0x258
Sep 06 07:04:07 af40s-vm kernel:  kthread+0xf4/0x110
Sep 06 07:04:07 af40s-vm kernel:  ret_from_fork+0x10/0x20
Sep 06 07:04:07 af40s-vm kernel: ---[ end trace 0000000000000000 ]---

These errors don’t occur on 6.10.3 or 6.9.9.

More research…

Perusing the kernel changelogs on kernel.org, it appears that someone from Broadcom/VMware has been checking in a lot of changes to the kernel for the vmwgfx driver since 6.10.3. My suspicion is that something in there is what’s causing this problem.

There are also some other checked-in changes for 6.10.8, so I’ll see if those fix the issues once Fedora pushes that one out.

1 Like

The 6.10.8 kernel has just been pushed out to F40. It appears to fix this issue, so you can disable 3D acceleration for the VMware VM once this kernel has been installed in the guest.

Unfortunately, I can’t confirm that kernel 6.10.8 has fixed the issue for me. :frowning:
I’m still greeted with a blank screen after booting.

For me, the issue seems to be fixed with VMware ESXi 7.0.3 and kernel 6.10.8 on Fedora 40 VM.

What VMware hypervisor product are you using, and if it’s a hosted product (Fusion or Workstation), what’s the host OS?

Can you log into the VM with ssh and review any system logging from there?

I’m using VMware Workstation 17 Player (17.5.2 build-23775571) on Windows 10.
I don’t have any means to connect via SSH to this VM, I guess, but I can still boot into 6.9.11 and try to grab some logs from the trials to boot into 6.10.x if this is possible.