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

> On Feb 11, 2025, at 4:01 PM, Mark Millard <marklmi-/[email protected]> wrote:
> 
> 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

It appears that vtnet (Virtio Net) interface fails to attach and the detach routine `ether_ifdetach()` is invoked.

Can you try to boot with the DEBUG kernel, for 15.0-CURRENT it is GENERIC without NODEBUG , and share
the panic and debug message ?


Best regards,
Zhenlei

> 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
> 
>