Date: Sat, 15 Feb 2025 16:12:35 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-virtualization@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: An inp_next() panic under arm64 Parallels [ during vtnet_attach() ]: how to avoid it? Message-ID: <C4107DA6-7CC1-4C4E-A635-A8B845908AC2@FreeBSD.org> In-Reply-To: <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com> References: <2BC05CE0-CD41-4F6C-8177-75BA1C107935.ref@yahoo.com> <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 11, 2025, at 4:01 PM, Mark Millard <marklmi@yahoo.com> wrote: >=20 > 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 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] >=20 > 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 > 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] >=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 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C4107DA6-7CC1-4C4E-A635-A8B845908AC2>