Date: Fri, 14 Feb 2025 22:35:57 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-virtualization@freebsd.org Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: An inp_next() panic under arm64 Parallels [ during vtnet_attach() ]: how to avoid it? [1 way: treat FreeBSD as a Linux] Message-ID: <E64D18FB-BEDB-4D6E-B4CF-D2A3223EC81D@yahoo.com> In-Reply-To: <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com> References: <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Hmm. This did not seem to have been sent at the time.] On Feb 11, 2025, at 00:01, Mark Millard <marklmi@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.) >=20 > The below example is for booting an official PkgBase > kernel.NODEBUG build: >=20 > 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: >=20 > # uname -apKU > FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n275286-dd78d987cb38 GENERIC-NODEBUG arm64 aarch64 1500031 1500031 >=20 >=20 > The below example is for booting my personal kernel build, > a NODBG build as well: >=20 . . . (making the message shorter) . . . >=20 > # 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 >=20 > (So: very similar. Both are non-debug builds.) >=20 >=20 > Is there a known way of avoiding this? >=20 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=C2=AE: = <Virt10 GPU> on virtio_pcil VT: Replacing driver "efifb" with new "virtio_gpu". Still, I can ssh in and use the FreeBSD instance. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E64D18FB-BEDB-4D6E-B4CF-D2A3223EC81D>