Re: An inp_next() panic under arm64 Parallels [ during vtnet_attach() ]: how to avoid it? [1 way: treat FreeBSD as a Linux]

[Hmm. This did not seem to have been sent at the time.]

On Feb 11, 2025, at 00:01, Mark Millard <[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
> 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]

Later below I indicate a way to avoid the above. But
it might be that panicking in this way is not really
a good handling of the type of context that I started
with.

> 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:
> 
. . . (making the message shorter) . . .
> 
> # 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?
> 

Well, one way of avoiding this is to tell Parallels
that the OS to be used is a Linux of category Other:
The vtnet_attach then works and the FreeBSD boots from
the external USB 3.1 Gen 2 media connection.

But the console display stops updating after:
'VT: Replacing driver "efifb" with new "virtio_gpu".'
is reported. (Serial only leaves teh text, video
clears the window content.)

. . .
pci0: unknown> at device 9.0 (no driver attached)
virtio_pcil: < VirtlO PCI (modern) GPU adapter> mem 0x10000000-0x13ffffff,0x14008000-0
x14008fff,0x14000000-0x14003fff at device 10.0 on pci0 vtgpu®: <Virt10 GPU> on virtio_pcil
VT: Replacing driver "efifb" with new "virtio_gpu".

Still, I can ssh in and use the FreeBSD instance.



===
Mark Millard
marklmi at yahoo.com