Re: panic in wscons booting current evbarm64 iso under virtualization on Apple Silicon

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 26/10/2026 00:52, John Klos wrote:
> Hi,
> Quick note: I've been using UTM to run aarch64 VMs for quite a while on an M4 MacBook Air. Today I updated from UTM version 4.75 to 5.08, and got a panic with VMs that worked just fine with 4.75.
> Although your panic and mine are different, perhaps try an older version as a data point?
> John
> [   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
> [   1.0000000]     2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
> [   1.0000000]     2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
> [   1.0000000]     2024, 2025, 2026
> [   1.0000000]     The NetBSD Foundation, Inc.  All rights reserved.
> [   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> [   1.0000000]     The Regents of the University of California.  All rights reserved.
> [   1.0000000] NetBSD 11.0_STABLE (GENERIC64) #0: Wed Sep  9 01:18:00 UTC 2026
> [   1.0000000] john%platypus.zia.io@localhost:/usr/obj-evbarm/sys/arch/evbarm/compile/GENERIC64
> [   1.0000000] total memory = 4073 MB
> [   1.0000000] avail memory = 3924 MB
> [   1.0000000] entropy: ready
> [   1.0000000] armfdt0 (root)
> [   1.0000000] armfdt0: using EFI runtime services for RTC
> [   1.0000000] simplebus0 at armfdt0: QEMU QEMU Virtual Machine
> [   1.0000000] simplebus1 at simplebus0
> [   1.0000000] acpifdt0 at simplebus0
> [   1.0000000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x13f800000
> [   1.0000000] ACPI: RSDP 0x000000013C150018 000024 (v02 BOCHS )
> [   1.0000000] ACPI: XSDT 0x000000013C15FE98 00005C (v01 BOCHS  BXPC 00000001      01000013)
> [   1.0000000] ACPI: FACP 0x000000013C15FA98 000114 (v06 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: DSDT 0x000000013C157518 001468 (v02 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: APIC 0x000000013C15FC18 00010C (v04 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: PPTT 0x000000013C15FD98 000060 (v02 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: GTDT 0x000000013C15D898 000068 (v03 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: MCFG 0x000000013C15FF98 00003C (v01 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: SPCR 0x000000013C15E818 000050 (v02 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: DBG2 0x000000013C15E898 000057 (v00 BOCHS  BXPC 00000001 BXPC 00000001)
> [   1.0000000] ACPI: 1 ACPI AML tables successfully acquired and loaded
> [   1.0000000] acpi0 at acpifdt0: Intel ACPICA 20241212
> [   1.0000000] cpu0 at acpi0: unknown CPU (ID = 0x610f0000), id 0x0
> [   1.0000000] cpu0: package 0, core 0, smt 0, numa 0
> [   1.0000000] panic: Trap: fatal Unknown Reason (Illegal Instruction): pc=ffffc000003fa3b8 sp=ffffc000010262e0 esr=02000000
> [   1.0000000] cpu0: Begin traceback...
> [   1.0000000] trace fp ffffc00001025e60
> [   1.0000000] fp ffffc00001025e90 vpanic() at ffffc00000514440 netbsd:vpanic+0x1a0
> [   1.0000000] fp ffffc00001025ef0 panic() at ffffc00000514524 netbsd:panic+0x44
> [   1.0000000] fp ffffc00001025f80 trap_el1h_sync() at ffffc000000afb5c netbsd:trap_el1h_sync+0x9c
> [   1.0000000] tf ffffc00001025fb0 el1_trap() at ffffc000000b2784 netbsd:el1_vectors+0x784
> [   1.0000000] ---- Unknown Reason (Illegal Instruction): trapframe 0xffffc00001025fb0 (304 bytes) ----
> [   1.0000000]     pc=ffffc000003fa3b8,   spsr=00000000604000c5
> [   1.0000000]    esr=0000000002000000,    far=0000000000000000
> [   1.0000000]     x0=00000000564d5868,     x1=00000000a9b2a797
> [   1.0000000]     x2=00000000ffff000a,     x3=0000000000005658
> [   1.0000000]     x4=0000000000000000,     x5=0000000000000000
> [   1.0000000]     x6=0000000000000000,     x7=000000860000000e
> [   1.0000000]     x8=ffffc00001026308,     x9=000000000000000e
> [   1.0000000]    x10=00000000564d5868,    x11=0000000000005658
> [   1.0000000]    x12=00000000a9b2a797,    x13=fffffc0004fa2fdc
> [   1.0000000]    x14=ffffc0017ade7000,    x15=ffffc00000c70938
> [   1.0000000]    x16=ffffc000000088d4,    x17=ffffc000011c6000
> [   1.0000000]    x18=ffffc000010264f8,    x19=ffffc000010263d0
> [   1.0000000]    x20=ffffc00000d6c078,    x21=ffff00013e802080
> [   1.0000000]    x22=ffffc000011b9f98,    x23=ffff00013e802080
> [   1.0000000]    x24=ffffc0017b4ddc5c,    x25=ffff00013e8b8d00
> [   1.0000000]    x26=0000000000000001,    x27=ffffc00000961998
> [   1.0000000]    x28=ffffc00000a100e0, fp=x29=ffffc000010262e0
> [   1.0000000] lr=x30=ffffc000003fb8a0,     sp=ffffc000010262e0
> [   1.0000000] ------------------------------------------------
> [   1.0000000] fp ffffc000010262e0 vm_cmd() at ffffc000003fa3b8 netbsd:vm_cmd+0x28
> [   1.0000000] fp ffffc000010262f0 vmt_probe() at ffffc000003fb89c netbsd:vmt_probe+0x3c


This is a qemu bug


https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg01794.html