An inp_next() panic under arm64 Parallels [ during vtnet_attach() ]: how to avoid it?

I took my existing media that I use to boot and
operate a Windows Dev Kit 2023 and a RPi5 (same
media moved between machines) and tried to have
Parallels on macOS boot the USB 3.2 Gen 2 capable
media plugged into MacBook Pro M4. The result was
as shown later below. (Warning: transcription involved.)

The below example is for booting an official PkgBase
kernel.NODEBUG build:

vpanic() at ypanic+0x1al
panic()  at panic+0x48
data_abort() at data_abort+0x334
handle_el1h_sync() at handle_el1h_sync+0x18
-- exception, est 0x96000004
inp_next() at inp_next+0x4c
in_pcbpurgeif0() at in_pcbpurgeif0+0x3c
in_ifdetach() at in_ifdetach+0xa0
if_detach_internal() at if_detach_internal+0x384
if_detach() at if_detach+0xac
vtnet_attach() at vtnet_attach+0x172c
device_attach() at device_attach+0x468
vtpci_legacy_probe_and_attach_child() at vtpci_legacy_probe_and_attach_child+0x90
vtpci_legacy_attach() at vtpci_legacy_attach+0x230
device_attach() at device_attach+0x468
bus_attach_children() at bus_attach_children+0x40
pci_attach() at pci_attach+0xf8
acpi_pci_attach() at acpi_pci_attach+0x1c
device_attach() at device_attach+0x468
bus_attach_children() at bus_attach_children+0x40
pci_host_generic_acpi_attach() at pci_host_generic_acpi_attach+0x38
device_attach() at device_attach+0x468
bus_generic_new_pass() at bus_generic_new_pass+0x10c
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
root_bus_configure() at root_bus_configure+0x44
mi_startup() at mi_startup+0x1f0
virtdone() at virtdone+0x6c
KDB: enter: panic
I thread pid 0 tid 100000 1
Stopped at kdb_enter+0x48: str xzr, [x19, #1920]

For reference:

# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT main-n275286-dd78d987cb38 GENERIC-NODEBUG arm64 aarch64 1500031 1500031


The below example is for booting my personal kernel build,
a NODBG build as well:

vpanic() at vpanic+0x1a8
panic() at panic+0x48
data_abort() at data_abort+0x330
handle_el1h_sync() at handle_el1h_sync+0x18
-- exception, esr 0x96000004
inp_next() at inp_next+0x4c
in_pcbpurgeif0() at in_pcbpurgeif0+0x40
in_ifdetach() at in_ifdetach+0x64
if_detach_internal() at if_detach_internal+0x1a8
if_detach() at if_detach+0x70
vtnet_attach() at vtnet_attach+0x1744
device_attach() at device_attach+0x468
vtpci_legacy_probe_and_attach_child() at vtpci_legacy_probe_and_attach_child+0x90
vtpci_legacy_attach() at vtpci_legacy_attach+0x230
device_attach() at device_attach+0x468
bus_attach_children() at bus_attach_children+0x40
pci_attach() at pci_attach+0xf8
acpi_pci_attach() at acpi_pci_attach+0x1c
device_attach() at device_attach+0x468
bus_attach_children() at bus_attach_children+0x40
pci_host_generic_acpi_attach() at pci_host_generic_acpi_attach+0x38
device_attach() at device_attach+0x468
bus_generic_new_pass() at bus_generic_new_pass+0x114
bus_generic_new_pass() at bus_generic_new_pass+0xb8
bus_generic_new_pass() at bus_generic_new_pass+0xb8
root_bus_configure() at root_bus_configure+0x48
mi_startup() at mi_startup+0x1f0
virtdone() at virtdone+0x6c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at kdb_enter+0x4c: str xzr, [x19, #2048]

# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #5 main-n275290-9ef38a01aea8-dirty: Wed Feb  5 19:45:09 PST 2025     root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500031 1500031

(So: very similar. Both are non-debug builds.)


Is there a known way of avoiding this?


===
Mark Millard
marklmi at yahoo.com