Message-ID: <ScE5lMhg6rlV47ttw0oUEWA5IsyxChuvN1pTOoj_KNj5rUpineEqR3GsPjNZl61xtXG4QS4v9v3ur4Ac0zI5GvdGEW_gWFJBD_FazYLcd_E=@proton.me>
Date: Tue, 13 Jan 2026 19:08:42 +0000
From: jollycar <jollycar@...ton.me>
To: Qu Wenruo <wqu@...e.com>
Cc: "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>, "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows installation on btrfs with kernels 6.18+ (works on 6.12 LTS)

Thanks for the response.

Module installation: DKMS via the virtualbox-host-dkms package. The dkms status output confirms vboxhost/7.2.4_OSE is compiled for each kernel including the broken ones (6.18.3, 6.18.5 (tkg), 6.19.0-rc3).

Regarding CPU type specification:

VirtualBox doesn't have qemu-style CPU model selection. The --cpu-profile option only supports "host" (full passthrough) or ancient CPUs (8086/80286/80386) which don't meet Windows 10 requirements.

Additional testing: I recently upgraded my desktop pc from Ryzen 9 5900X to 9950X3D (reusing same disks and linux install) and the regression occurred identically on both CPUs. Also tested custom compiled TKG kernels (6.12/6.18 with bore scheduler). The behavior matches the Manjaro kernels exactly (6.12 works, 6.18 breaks).

Regards,
Jollycar

On Monday, January 12th, 2026 at 8:48 PM, Qu Wenruo <wqu@...e.com> wrote:

> 
> 
> 
> 
> 在 2026/1/13 02:03, jollycar 写道:
> 
> > Qemu/libvirt test results on kernel 6.18.3:
> > 
> > Setup:
> > - Virtualization: qemu via libvirt (virt-manager)
> > - Disk format: qcow2
> > - Disk location: /data/virtual-os/win10-qemu-test.qcow2 (same btrfs subvolume as VirtualBox VMs)
> > - COW disabled on disk image (chattr +C)
> > - ISO: Same Windows 10 ISO used in VirtualBox tests
> > - Guest: Windows 10
> > 
> > Result:
> > Windows 10 installation completed successfully without any crashes. Installation proceeded through all phases including multiple reboots and reached the desktop without issues.
> > 
> > Summary of all tests on kernel 6.18.3:
> > - VirtualBox 7.2.4: Crashes during installation (all cache/mtype configurations tested)
> > - Qemu via libvirt: No crashes, installation completes successfully
> > 
> > Both using the same btrfs filesystem, same subvolume location, same Windows ISO, and COW disabled.
> 
> 
> Thanks a lot, this looks like there is something wrong related to the
> VBox out-of-tree kernel module.
> In that case, the btrfs community is not going to help much unfortunately.
> 
> Mind to share how is the out-of-tree kernel module installed?
> The pre-compiled one from the distro? The DKMS one or something else?
> 
> 
> And just some guesses, can VBox specify what type of CPU (and extensions
> like SSE/AVX) it uses?
> If so (like qemu), mind to check if you can specify some CPU types
> without some newer extensions while still meets the minimal CPU
> requirement of Windows 10?
> 
> I'm wondering if it's some extension handling not done properly, which
> is commonly utilized by checksums.
> Thus triggers the checksum mismatch errors inside Windows.
> 
> Thanks,
> Qu
> 
> 
> > On Sunday, January 11th, 2026 at 8:43 PM, Qu Wenruo wqu@...e.com wrote:
> > 
> > > 在 2026/1/11 21:39, jollycar 写道:
> > > 
> > > > Storage configuration details:
> > > > 
> > > > Storage format: VDI (VirtualBox Disk Image)
> > > > Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
> > > 
> > > OK, this means it's not related to the direct IO changes in newer kernels.
> > > 
> > > When COW is disabled, data checksum is also disables, thus direct IO is
> > > still doing the true zero-copy behavior.
> > > 
> > > This ruled out the btrfs direct io change, but this means I have no clue
> > > what is going wrong at all now.
> > > 
> > > > Controller: IntelAhci (SATA)
> > > > Default configuration: hostiocache on, mtype normal
> > > > 
> > > > Cache and media type testing on kernel 6.18.3:
> > > > - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> > > > - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> > > > - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> > > > 
> > > > None of the configurations provide a working solution - they only delay the crash.
> > > > 
> > > > On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> > > > 
> > > > I have not yet tested with qemu/libvirt. Should I proceed with that test?
> > > 
> > > Yes please. Libvirt/qemu is a more common solution among developers.
> > > If you can reproduce it using libvirt/qemu, more btrfs developers can
> > > try to reproduce it and look into it.
> > > 
> > > And if not, the cause may shift towards vbox other than btrfs.
> > > 
> > > Thanks,
> > > Qu
> > > 
> > > > On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo wqu@...e.com wrote:
> > > > 
> > > > > 在 2026/1/11 20:33, jollycar 写道:
> > > > > 
> > > > > > #regzbot introduced: v6.12..v6.18
> > > > > > 
> > > > > > [1.] One line summary of the problem:
> > > > > > VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
> > > > > > 
> > > > > > [2.] Full description of the problem:
> > > > > > Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
> > > > > > 
> > > > > > [3] Kernel & Hardware:
> > > > > > - Kernel versions tested:
> > > > > > * Working: 6.12.63-1
> > > > > > * Broken: 6.18.3-2, 6.19.0-rc3-1
> > > > > > - Distribution: Manjaro Linux
> > > > > > - Architecture: x86_64
> > > > > > - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
> > > > > > 
> > > > > > [4.] Filesystem and storage:
> > > > > > - Root filesystem: btrfs on LUKS encryption
> > > > > > - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
> > > > > > - VM storage: separate btrfs subvolume
> > > > > 
> > > > > What's the storage file configuration? Like what's the cache mode setting?
> > > > > I don't know VBox at all, but there may be something similar to
> > > > > libvirt's cache mode (none/unsafe/writethrough etc).
> > > > > 
> > > > > More importantly, will tweaking the cache mode change fix the broken
> > > > > kernels?
> > > > > If so it may point to direct IO related behavior changes.
> > > > > 
> > > > > And what's the storage file format? QCOW2? RAW? Or whatever format
> > > > > provided by Vbox?
> > > > > 
> > > > > And one final question, have you tried qemu (or libvirt + qemu) and can
> > > > > it still be reproduced with qemu?
> > > > > As I'm wondering if the direct IO related change will even affects qemu
> > > > > 
> > > > > Thanks,
> > > > > Qu
> > > > > 
> > > > > > - btrfs device stats: all zeros (no errors)
> > > > > > 
> > > > > > [5.] Reproduction:
> > > > > > - Boot kernel 6.18.3-2 or 6.19.0-rc3
> > > > > > - Start VirtualBox 7.2.4 r170995
> > > > > > - Create new Windows 10 or Windows 11 VM
> > > > > > - Begin OS installation
> > > > > > - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
> > > > > > - Issue is 100% reproducible on 6.18+, never occurs on 6.12
> > > > > > 
> > > > > > Additional context:
> > > > > > - Host system remains completely stable during VM crashes
> > > > > > - No btrfs errors in dmesg or device stats (all zero)
> > > > > > - Issue persists across multiple 6.18/6.19 releases over one month
> > > > > > - VirtualBox 7.2.4 modules load successfully on all kernel versions
> > > > > > 
> > > > > > Regards,
> > > > > > Jollycar

Powered by blists - more mailing lists