[Hmm. This did not seem to have been sent at the time.] On Feb 11, 2025, at 00:01, Mark Millard <mark...@yahoo.com> 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
