On Tue, 31 Dec 2024 18:22:39 +0000
Mark Harmstone <maharmstone@xxxxxxxx> wrote:
> Hi all,
>
> I've encountered a really weird bug when trying to run the fstest
> generic/476 in a loop on a microvm VM. The block device is a
> virtio-blk-device, formatted as btrfs.
>
> With acpi=on, it eventually grinds to a halt, and prints a hang message.
> I tracked the problem down to be within wait_dev_supers, i.e. it's
> apparently issuing a write for the superblock that never returns. The
> strange thing is that with acpi=off everything works as it should.
>
> acpi=off adds this to the cmdline: virtio_mmio.device=512@0xfeb00e00:12
>
> acpi=on adds this to the DSDT:
>
> Device (VR07)
> {
> Name (_HID, "LNRO0005") // _HID: Hardware ID
> Name (_UID, 0x07) // _UID: Unique ID
> Name (_CCA, One) // _CCA: Cache Coherency Attribute
> Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> {
> Memory32Fixed (ReadWrite,
> 0xFEB00E00, // Address Base
> 0x00000200, // Address Length
> )
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
> {
> 0x0000000C,
> }
> })
> }
>
> ...and to my untrained eye it's not obvious if there's something wrong
> there.
>
> Does this ring a bell to anyone? Is the bug in Qemu, the kernel, or am I
> inadvertently doing something stupid? I'm happy to help someone
> reproduce this.
on the 1st glance nothing looks unusual,
CCing Michael and Gerd in case they see where it might break.
>
> Thanks
>
> Mark
