From nobody Sat Feb 15 08:12:35 2025 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yw1qs5Slnz5nByB; Sat, 15 Feb 2025 08:12:41 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yw1qs3WWLz3w5D; Sat, 15 Feb 2025 08:12:41 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739607161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1yW4yHmDW7spOHHf+fbJLV5vDShK4PTF2IqRvQ41oq0=; b=Vj28yBR8EFouCYzYkzHZ7flq3w9XOm89YQIw8iCxTY/M3gW9Q/IGyFDIsfEYnRqbc3kCZ4 lkq6BZEyWNy28vAl+6I0jGOJDRLOFcCI4oMS48X5I6NRnv8Ids4IabH40l/ptcIHKEwpZn LRtb2ZdaQgtdM3fzFDO3KKrtegsga/W3A0Ji7FaDxi9mdsnwD3IJ0RVbiv9JyxsEiyI6gF l9KSTzZJHlPNmqqHXieQ7Lr5gDmUTalQv4COhQe/f1DeR7pJ2K37r6f6FI+gSYPJu74/ih m2BgHwxOZy7WbifIg0YW9C+Wok/+cSUh2klTeGGlGyXs7dKIV3Z0uI2/7x3UvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739607161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1yW4yHmDW7spOHHf+fbJLV5vDShK4PTF2IqRvQ41oq0=; b=RXGLEjM/fDJSVyTgPi96GkF4yRikNl6Y65Qsn0Lv5ymlzaDvjAdCLJCfKc/ovL1gmLGAY2 1WaE7y5635+EJqycBlCHZiWX4Ld/GSMHhiLwhiHErlVPXFN9Q9fPHAxNctr3vvsYKzzm2p q3TZcDqLAidfnCX5s/EOzdy9lHyyzePhQ+PuoR0afX3Y+UJjNlRe8eFYSBJdPMdW/R9hiC qOeY6HkNQ1zHH7Eq2+4gn/UiNGbPzxKkBzxxyjxSCScWU6AoQNqT9vQHy9OsuloycUZ012 44Ze8vJmm/AybQ8TnvAkMswPdaf3aaYXrwo2A5UzQ16kFhgxZ9u41fAzyj0DNw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1739607161; a=rsa-sha256; cv=none; b=MUpzn77QHES+OPB5fs7gjtDS9x4fYpWEzk5xHXKRih8bjSURbLrlJ4vqZqJTQy+KFi2hFt VVLN+3R68hY1/eY4hW64NC/7e1qQvgJIJaoXf2N1dF+F1Jd7GqWSkffU4wBM4sMcU2l3fl 8dxlqbYQ5zCaQaT0/SN+95bLCpWYenJJTqzlbRP2Cug5M0vR0lZ+rjilJQcnBocT1D1O1g NOA7td4xPhXR2P9veKLIgnAv1vRSbTwy3gEN9I9thn2HaRK9FmLaCH5Bp1IXG/dKWjMsKV fCwynNxU4DD1rGZ+HGPwdlRSjVwfA6WOb2VjLQ3ZD8JaPfv0DTzQBT5+7MHDRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Yw1qr2Zqcz14dl; Sat, 15 Feb 2025 08:12:40 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=us-ascii List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: An inp_next() panic under arm64 Parallels [ during vtnet_attach() ]: how to avoid it? From: Zhenlei Huang In-Reply-To: <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com> Date: Sat, 15 Feb 2025 16:12:35 +0800 Cc: freebsd-virtualization@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BC05CE0-CD41-4F6C-8177-75BA1C107935.ref@yahoo.com> <2BC05CE0-CD41-4F6C-8177-75BA1C107935@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3696.120.41.1.10) > On Feb 11, 2025, at 4:01 PM, Mark Millard 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