Hi, thanks for the report.
On Tue, 25 Feb 2025, Jan wrote: > i tried this question on @misc but did not get a response. > Hope it is okay to ask here after a few weeks? > > I used a Qotom Box with 1G Interfaces 8G Ram and i5 8th generation > for some years, but recently i changed due to various reasons from > hardware to a qemu-vm (ArchLinux Host) on another host. The OpenBSD > Box/VM also routes / pf between some internal vlans. > > Everything seems to work great and reasonably fast, as i'm used from > OpenBSD. > > But i think i hit a small bug or perhaps a known limit (i did not find > anything in the man pages though): > > I'm doing the vlan-tagging on the VM-Host-Side, so i have 9 interfaces > that connects to a bridge on the qemu host, and one interface for the > Internet-Uplink which connects also via a hostbridge, so 10 interfaces > alltogether. > > If i add more than 9 vio Interfaces to the qemu-vm-config, OpenBSD > boots only to "fd0 at fdc0 drive 1: density unknown". I'm using stable. > > As a workaround, i added the last interface as a intel-nic, and > everything works fine again. > > dmesg with added ifconfig from a working config: > https://me.zediria.de/logs/dmesg-working.txt > > serial-boot-output from a failure config (stable): > https://me.zediria.de/logs/dmesg-working.txt > > I can reproduce this on a different machines with the same qemu > options / version. The qemu-version is 9.2.0 (Package-Version > Archlinux: 9.2.0-2) > > Here is how i fire up the OpenBSD vm using QEMU: > https://me.zediria.de/logs/qemu.txt > > I tried the same configuration with a Linux Guest, no problems. > It is completly irrelevant if i configure the interfaces in OpenBSD or > not (i think the boot stops long before the network scripts) I can reproduce the issue. The problem seems to be that if there are too many network devices, the interrupt slots on cpu0 run out and later devices including the block device get interrupt slots on other cpus. But at the time that the root file system is mounted, the other cpus are not running yet, and the block device won't work, causing the hang. A workaround is to set the pci addresses of the network devices explicitly on the qemu command line with addr=X, starting at 5 (the X value must be hex). Then qemu will place the block device before the network devices and the block device will get interrupt slots on cpu 0. Another workaround is to limit the msix vectors for the network devices with vectors=2. Then the interrupt slots on cpu 0 will run out later. I don't know yet how a fix in openbsd could look like. > > I tried upgrading to a the latest snapshot, but the bsd.upgrade kernel > is not finding the storage device, so i stopped trying that. > (Error: "vioblk0 at virtio9virtio9: Feature negotiation failed") I think this issue has been fixed in April. Cheers, Stefan
