From nobody Thu Feb 22 18:10:56 2024 X-Original-To: bugs@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 4Tgh5s44Mfz5B6gW for ; Thu, 22 Feb 2024 18:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tgh5s0QbDz4bSV for ; Thu, 22 Feb 2024 18:10:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708625457; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sDnk+iT3/lMcPKMHKy5x2PJKhM5rNsZfOI+fB7yeAYk=; b=Ozos3EhWhQOjG19j3g09L5c1i1n2+OhFvpYtw2kX4m9zwdk4xdM+PVLgRBex0q3reypD64 WQon7MBGWaBL7FsmAxQEf8Wcg5tgPXv0CQwsU4xsD9dmCinAV/TRuboYBEc+NR+aRFkaZ9 g8mYq1fW1m6zZwJq9ovtcJFF816EaG2ctZKwb+5LY3oTWrfrjZ6M4avPEbFrFi2ixDNn6b QF/HD8Hd1Iles30wDWZACcIkE65XqtH5U+YiOodwJY3jH3ECLXuHzDYxqJggnivHfNVahl QJKTK24nE4LiBXayY0oJUgpOcwsnxE5FpvZQWoNhks3VklHcEllFMT0Kyr1MLQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708625457; a=rsa-sha256; cv=none; b=Is5o2pKBz09ijhqZK9cRMJTse+dHjg1qJbwnUQJ5+1qkdDFbKtlZ5AFrD7lePTfUJu8o0u gBn84Xjm2BxQaMWv8jLd1S9MO383IE8JZHR+areSI5wwnGJnVkZPEIzB5rX4DfYgh3QVnI U4u2nj1R3bDWTkotYvhSDk+oW8GHkIXjRIjYwgr6zijSkG6Jowa1NnvHT7jtwFrlhgBIN1 4z4CYU0DFWWYe4SWych5GKA9oZaWS3JEqON0M2wFKyOo3sWY7AzSFfLmgh6fuXyxZrJ0zU Toax6X1eaqFHcbl8v2rE3h44QeLTzk8OMPlnEBdL4dEIjR39AYPe9eF0+rKDaw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Tgh5r6cXpzj6p for ; Thu, 22 Feb 2024 18:10:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 41MIAuuv083944 for ; Thu, 22 Feb 2024 18:10:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41MIAucY083942 for bugs@FreeBSD.org; Thu, 22 Feb 2024 18:10:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277211] panic: Unhandled external data abort - handle_el1h_sync - --- exception, esr 0x96000410 - wait_fw_init - mlx5_load_one Date: Thu, 22 Feb 2024 18:10:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277211 --- Comment #5 from John Baldwin --- Ah, looks like the dmesg from Dave does actually include this patch as it h= as this line of output: mlx5_core0: translate 0x14082000000 -> 0x24082000000 That looks correct, but unfortunately, we only display the ranges in bootverbose for FDT, not ACPI. The patch below fixes the pcib driver to al= ways log the ranges which would be useful to confirm the window: diff --git a/sys/dev/pci/pci_host_generic.c b/sys/dev/pci/pci_host_generic.c index 386b8411d29a..46b84ff3004b 100644 --- a/sys/dev/pci/pci_host_generic.c +++ b/sys/dev/pci/pci_host_generic.c @@ -83,6 +83,7 @@ pci_host_generic_core_attach(device_t dev) uint64_t phys_base; uint64_t pci_base; uint64_t size; + const char *range_descr; char buf[64]; int domain, error; int flags, rid, tuple, type; @@ -179,6 +180,7 @@ pci_host_generic_core_attach(device_t dev) switch (FLAG_TYPE(sc->ranges[tuple].flags)) { case FLAG_TYPE_PMEM: sc->has_pmem =3D true; + range_descr =3D "prefetch"; flags =3D RF_PREFETCHABLE; type =3D SYS_RES_MEMORY; error =3D rman_manage_region(&sc->pmem_rman, @@ -186,12 +188,14 @@ pci_host_generic_core_attach(device_t dev) break; case FLAG_TYPE_MEM: flags =3D 0; + range_descr =3D "memory"; type =3D SYS_RES_MEMORY; error =3D rman_manage_region(&sc->mem_rman, pci_base, pci_base + size - 1); break; case FLAG_TYPE_IO: flags =3D 0; + range_descr =3D "I/O port"; type =3D SYS_RES_IOPORT; error =3D rman_manage_region(&sc->io_rman, pci_base, pci_base + size - 1); @@ -219,6 +223,10 @@ pci_host_generic_core_attach(device_t dev) error =3D ENXIO; goto err_rman_manage; } + if (bootverbose) + device_printf(dev, + "PCI addr: 0x%jx, CPU addr: 0x%jx, Size: 0x%jx, Type: %s\n", + pci_base, phys_base, size, range_type); } return (0); That said, it seems like the translation is correct given the prefetch wind= ow used for the pcib1 bridge between pcib0 and the mlx5 device: pcib1: at device 0.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0x30000000-0x301fffff pcib1: prefetched decode 0x14080000000-0x14083ffffff And this allocation of mlx5's BAR: map[10]: type Prefetchable Memory, range 64, base 0x14082000000, si= ze 25, enabled pcib1: allocated prefetch range (0x14082000000-0x14083ffffff) for rid 10 of pci0:1:0:0 It is odd for a register bar to be in a prefetch BAR. It might be good to = see a verbose dmesg from before to see how the bridge and and mlx5 BAR were configured before. --=20 You are receiving this mail because: You are the assignee for the bug.=