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

[Chris Hanson <cmhanson%eschatologist.net@localhost>]

On Oct 25, 2026, at 5:50 PM, Jonathan A. Kollasch <jakllsch%kollasch.net@localhost> wrote:
> 
> It looks like what happened is genfb(4) called wsdisplay_cnattach(), and
> then viogpu(4) called it again, and wsdisplay_cnattach() insists on only
> being called once.  The question becomes why both genfb and viogpu are
> trying to run what's probably the same framebuffer as console.

I think what may be going on is that genfb(4) is being matched because a generic frame buffer shows up in the device tree:

[   1.0000040] genfb0 at simplebus1: Simple Framebuffer (800x600 32-bpp @ 0x13bd00000)
[   1.0000040] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)

and viogpu(4) is being used because that generic frame buffer is a virtio-ramfb device in QEMU and thus *also* found via VirtIO:

[   1.0000040] virtio33 at pci0 dev 2 function 0
[   1.0000040] virtio33: GPU device (id 16, rev. 0x01)
[   1.0000040] viogpu0 at virtio33: features: 0x110000000<V1,INDIRECT_DESC>
[   1.0000040] virtio33: interrupting at irq 37

Would this be a QEMU bug, or a bug in the handling/interaction of device tree and VirtIO in NetBSD?

  -- Chris