Message-ID: <FmCqd98aDZ5GTLc-1FUc4NRHRhDEDUDy1ylzO4rrFy_mV1zgC2tnmht5ov8px3ME3pBa6dioALVRD_tDKC3FhdUd4alND6G5g2bx8N7R154=@proton.me>
Date: Mon, 12 Jan 2026 15:33:14 +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)

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.


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