From nobody Sun Dec 29 02:45:37 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 4YLNrf26MFz5jdSh for ; Sun, 29 Dec 2024 02:45:38 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YLNrd6glQz4cN2 for ; Sun, 29 Dec 2024 02:45:37 +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=1735440337; 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=CWB/mELBNvV3ZeaqwuU1g9RD14QvjIEMTiymk287XFs=; b=U1i5nZqW+AXVMlidFOJ0exBzAMMsJJWqCNuoKNJGBM05h2jyFJI8yQl84M8ud+ZP40XlE7 BKWblJxWRSjcQ6MZ+YER6HeuaTHtleZR1elBB7wl0WqAV9tDsz4lyQ9vyv1EO/2VVXgalI +4nz+4WTNzlQ5ehoJmp4nQCO4lEDOQwrJxLI6ZjpAyzvReUxPdneJOBchxciRP1/AdTLxI I5EoJ6Ig/0ZUWPzH5+bzpuIH3SM3fKwwaxDlgPN7u+xjhzWNC9+FX4A2zq4F08qeP5AfW/ R0gdmyVu4I0Q0K0TAvItuuHSXnFI7wE8uADym6kMFv6f4mMgwYwvHHyaZHX2JA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1735440337; a=rsa-sha256; cv=none; b=eXtkc2pxIsfBMAKT+xZg9Of+2HDh4AfM/4bYpIdFIrPaJtxGoZjfQCQi47y2wmSJhBrzHm QaF9F7CUx1I++/Nu+ZFRJ+YGfZi4vYiC8l4PT21Hzkyt0j2vWh3RkZNG5HgYzWP3bx6Ui+ HbGNutbIaiifmX93GUNx1oj1YDQ6hRW/0mQaHY3xQat6NZaeejfjiOFstj4362qRsIpyb2 AmBJo1X6V0PCBji/96+CL4SGOgcBmMBVWvCeqqoU0VtRF/Id09eBFQCiEqEQ85vbA0u5XC D1LBFiN08OH7Zi1L8Q/5hMkv6S26V1Lp2m0algc1IWADnZdsuJ1Zu0sh7FNlfQ== 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 4YLNrd5zy0zqcQ for ; Sun, 29 Dec 2024 02:45:37 +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 4BT2jbki029982 for ; Sun, 29 Dec 2024 02:45:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4BT2jbfv029981 for bugs@FreeBSD.org; Sun, 29 Dec 2024 02:45:37 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 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko Date: Sun, 29 Dec 2024 02:45:37 +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: 13.1-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? 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=3D267028 --- Comment #336 from Mark Millard --- (In reply to George Mitchell from comment #335) For reference: going backwards through the found_modules list (via also using my extra recorded data) is the following. It is pairs of my modlist_newmod_hist and then a the prior node's link.tqe_next value that should agree with the the prior modAddr. (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos] $48 =3D {modAddr =3D 0xfffff80004718180, containerAddr =3D 0xfffff8000362f3= 00, modnameAddr =3D 0xffffffff82ea6025 "amdgpu_raven_vcn_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-1].modAddr->link.tqe_next $49 =3D (struct modlist *) 0xfffff80004718180 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-1] $50 =3D {modAddr =3D 0xfffff800047182c0, containerAddr =3D 0xfffff8000362f4= 80, modnameAddr =3D 0xffffffff82e62026 "amdgpu_raven_mec2_bin_fw", version =3D = 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-2].modAddr->link.tqe_next $51 =3D (struct modlist *) 0xfffff800047182c0 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-2] $52 =3D {modAddr =3D 0xfffff80003647d40, containerAddr =3D 0xfffff800031691= 80, modnameAddr =3D 0xffffffff82e1e010 "amdgpu_raven_mec_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-3].modAddr->link.tqe_next $53 =3D (struct modlist *) 0xfffff80003647d40 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-3] $54 =3D {modAddr =3D 0xfffff80004718240, containerAddr =3D 0xfffff800031693= 00, modnameAddr =3D 0xffffffff82e12009 "amdgpu_raven_rlc_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-4].modAddr->link.tqe_next $55 =3D (struct modlist *) 0xfffff80004718240 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-4] $56 =3D {modAddr =3D 0xfffff800035bb8c0, containerAddr =3D 0xfffff800031696= 00, modnameAddr =3D 0xffffffff829f6010 "amdgpu_raven_ce_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-5].modAddr->link.tqe_next $57 =3D (struct modlist *) 0xfffff80000000007 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-5] $58 =3D {modAddr =3D 0xfffff80004b90140, containerAddr =3D 0xfffff80004c420= 00, modnameAddr =3D 0xffffffff829ef000 "amdgpu_raven_me_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-6].modAddr->link.tqe_next $59 =3D (struct modlist *) 0xfffff80004b90140 (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-6] $60 =3D {modAddr =3D 0xfffff80004b90180, containerAddr =3D 0xfffff80004c423= 00, modnameAddr =3D 0xffffffff829e7025 "amdgpu_raven_pfp_bin_fw", version =3D 1} (kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-7].modAddr->link.tqe_next $61 =3D (struct modlist *) 0xfffff80004b90180 $57's (modlist_newmod_hist_pos-5's) link.tqe_next does not agree with $56's modlist_newmod_hist[modlist_newmod_hist_pos-4].modAddr , again by hav= ing the value 0xfffff80000000007 . The code did not stop when 0xfffff80000000007 was stored into that link.tqe_next instance, unfortunately. There is something just before that was unusual in the core.9.txt ( or, as named here, core.txt.9 ): I think it is the first time I've seen any "WARNING !drm_modeset_is_locked . . ." messages BEFORE the first part of the first trap(/panic?) reported. In this example, it looks like: <6>[drm] Initialized amdgpu 3.40.0 20150101 for drmn0 on minor 0 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/ports/graphics/drm-510-kmod/work/drm-kmod-drm_v5.10.163_7/drivers/gpu/= drm/drm_atomic_helper.c:619 . . . WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/ports/graphics/drm-510-kmod/work/drm-kmod-drm_v5.10.163_7/drivers/gpu/= drm/drm_atomic_helper.c:894 kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: modlist_lookup: a prior tqe_next changed! . . . I wonder if that is some sort of consequence of my attempt to have the hardware monitoring three 8-Byte address ranges for being written to. As stands, I do not see how the results provide any specific additional useful-evidence that I can identify. The only thing that I've thought of is to add printf reporting of the address argument passed to each attempted db_hwatchpoint_cmd use to help validate that I have that code doing what I intended. --=20 You are receiving this mail because: You are the assignee for the bug.=