Workstation 18 reboots randomly

Support
1

hello

  • the Workstation 18 is randomly rebooting by itself (without any action on my part)
  • this issue makes working pretty difficult as it won’t even warn you to close unsaved work
  • happened multiple times today
  • never experienced this issue on the previous version 17
  • Host is Linux + Virtual Box 7.1.6

anything we can do to fix it?
thanks

2 Likes
2

The only thing you can attempt is to go through the checklist.

General VirtualBox Troubleshooting Steps

2 Likes
3

I started facing the same issue as the OP. Never experienced it under Whonix 17 either. Following the general tips you linked didn’t fix it. I don’t know if it can be fixed, just wanted to inform that this is not an isolated issue.

2 Likes
4

Possible solution:

2 Likes
5

Required for further debugging: Share each checklist step and its result.

2 Likes
6

I’m affected by the same issue and was able to capture the actual kernel oops via a serial console. It is a regression in the Debian kernel: 6.12.74+deb13+1-amd64 works fine, 6.12.111+deb13-amd64 crashes inside the vmwgfx driver.

Setup

  • Host: macOS 14.8.9, VirtualBox 7.1.10
  • Guest: Whonix-Workstation-LXQt 18 (Wayland / labwc)
  • Guest Additions in VM: 7.2.20 r175154
  • Graphics Controller: VMSVGA, 3D acceleration disabled, 128 MB VRAM
  • Workstation: [N] vCPU, GB RAM

Symptoms

  • Workstation reboots by itself every 2–10 minutes, without any warning.
  • Trigger: using Firefox (lots of screen redraws). Without a browser it is more stable.
  • Host VBox.log shows only ACPI: Reset initiated by ACPI, i.e. the guest itself resets — no Guru Meditation, no host OOM.
  • journalctl -b -1 simply ends mid-session (no shutdown sequence), and there are no OOM messages, so this is a kernel panic, not lack of memory.

Root cause (captured via serial port, console=ttyS0,115200 ignore_loglevel)

BUG: unable to handle page fault for address: ffff8a2f00000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 39e01067 P4D 39e01067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 UID: 0 PID: 34 Comm: kworker/u10:1 Tainted: G        W  OE K    6.12.111+deb13-amd64 #1  Debian 6.12.111-1
Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE, [K]=LIVEPATCH
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Workqueue: events_unbound commit_work [drm_kms_helper]
RIP: 0010:dma_pool_alloc+0x40/0x200
CR2: ffff8a2f00000000
Call Trace:
 <TASK>
 vmw_cmdbuf_alloc+0xbd/0x200 [vmwgfx]
 vmw_cmdbuf_reserve+0x142/0x170 [vmwgfx]
 vmw_cmd_ctx_reserve+0x24/0x60 [vmwgfx]
 vmw_stdu_bind_st+0x6b/0x100 [vmwgfx]
 vmw_stdu_primary_plane_atomic_update+0xa8/0x1d0 [vmwgfx]
 drm_atomic_helper_commit_planes+0x112/0x320 [drm_kms_helper]
 drm_atomic_helper_commit_tail+0x48/0x90 [drm_kms_helper]
 vmw_atomic_commit_tail+0x1b/0x80 [vmwgfx]
 commit_tail+0x94/0x130 [drm_kms_helper]
 process_one_work+0x18b/0x340
 worker_thread+0x191/0x2f0
 kthread+0xd2/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>
note: kworker/u10:1[34] exited with irqs disabled
note: kworker/u10:1[34] exited with preempt_count 1
Kernel panic - not syncing: Oopsed too often (kernel.oops_limit is 1)

So the reboot is caused by kernel.oops_limit=1 (expected Whonix hardening behaviour) — the real bug is the oops in vmwgfx command buffer allocation from the DMA pool during a screen-target plane update. The faulting address has its lower 32 bits zeroed, which looks like a use-after-free / memory corruption of the DMA pool free list (my guess).

At driver load the usual message is present:

vmwgfx 0000:00:02.0: [drm] *ERROR* vmwgfx seems to be running on an unsupported hypervisor.
vmwgfx 0000:00:02.0: [drm] Using command buffers with DMA pool.

Regression

  • 6.12.74+deb13+1-amd64 — stable, no reboots with the same VM settings and the same Firefox usage.
  • 6.12.111+deb13-amd64 — crashes after 2–10 minutes.

So something between Debian 6.12.74 and 6.12.111 broke vmwgfx under VirtualBox VMSVGA.

Workarounds tried

  • Disabling 3D acceleration: was already disabled — crash still happens.
  • VBoxSVGA and VBoxVGA: no crashes, but the desktop is extremely laggy and practically unusable.
  • Booting the older kernel 6.12.74 via GRUB “Advanced options”: works perfectly. Currently using this, with the package kept via apt-mark manual.

Possibly unrelated

The [W] taint comes from a warning early at boot (12 s, before vmwgfx is loaded), while udev-worker was loading ahci and tirdad:

WARNING: CPU: 1 PID: 319 at kernel/rcu/tree_plugin.h:826 rcu_sched_clock_irq+0x7cb/0xb60
Modules linked in: ahci(+) ... vboxguest(OE) ... tirdad(OEK+) ...
CPU: 1 UID: 0 PID: 319 Comm: (udev-worker) Tainted: G           OE K    6.12.111+deb13-amd64

Not sure if it is related; the VM runs normally for ~5 minutes after it.

I can provide the full serial log or test intermediate kernel versions if that helps narrowing it down. Should this also be reported to the Debian kernel team / upstream vmwgfx maintainers?

2 Likes
7

Yes. Best if reported upstream. Seems your AI agent did a pretty good job at diagnosing this. Maybe your AI agent can also figure out where to best report this upstream.

Is this still reproducible with latest upstream Linux kernel? Maybe your AI agent can set up a separate, secure test environment (on a spare computer and/or VM or rented server depending on your requirements).

Your AI agent may even be capable of writing a patch that may or may not be useful for upstream to fix this issue.

AI based bug reports may or may not be permissible according to upstraem policy.

Related:

1 Like
8

As a stop-gap, and assuming the analysis posted by @redvine123 is correct, it might be worth trying other emulated graphics options in VirtualBox, like VBoxSVGA.

9

Update / resolution: the crashes are gone after updating the host VirtualBox to 7.2.20 r175154 (matching the Guest Additions version) together with the guest kernel 6.12.113+deb13. VMSVGA, 3D disabled, Firefox — stable so far.

So my earlier “kernel regression” conclusion was premature: 6.12.74 worked with the old VirtualBox, but the actual fix seems to be the VirtualBox update. I changed both at once, so I can’t fully rule out the kernel

1 Like