From nobody Tue Jun 03 10:08:00 2025 X-Original-To: freebsd-current@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 4bBRHQ4mY0z5xQWL for ; Tue, 03 Jun 2025 10:08:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bBRHP0g4Dz3wxY for ; Tue, 03 Jun 2025 10:08:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zabbadoz.net header.s=20240622 header.b="Sea+I0Q/"; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2003:a:140a:2200:6:594:fffe:19 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=pass (policy=none) header.from=zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id EE22CA64805; Tue, 03 Jun 2025 10:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net; s=20240622; t=1748945282; bh=AbOFUvUfu2IlEz30v/CZ9WKJI/s3zYlJb1VpgVR4IDw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Sea+I0Q/DlUIEaO7UrrEZ6/Fk3uP9HGoxV3frBvYJKNJyegirTNGDTfswZ0jjtjmD gsC9KABphxfLkKhZcnwU8AFgTrx3QavxtYkzK6s0vbfZ3khUb2ZSHim2nvBMNglTUQ 1PRLSyL/l8pj4fVzAyDiJCRBnIHcggdblH6G7HOlTBeugX60hQOHuJ3IN5gwvk1U4B ETIvRWYKuRucsCES434HOMROp4G4pOk8lOFU+TxjKVcEF/+rvRyfw9chYbhGp7LefL 2e1o0MxjgmwfX/EnTK/gNUYQgViQOXtyyiK6nV4DQOopFGKLdECfeYpI1YlaEKUNCd 1lxHV5VfsVxkr+tq3gy2Dk3C5AacA+txj7Q9wKxLnWIzmSdmKiOTfIvpCws+Y74QFb Nhyn2wlzVjEQKFpmbFxxVo5/83EFc8fwEutypXRi95nHIIJWU+qUDFakTt9NrL4WwR lJ56+CYlYbU17EtjP7By2D7ZWdIK0CUlUeB4VO3zaQDt7vD6ldbEiXiMUXlq+6+qSI +cnVfG7ZLXFK810SvZUZ7EM66mSTQSX9C+XtoUjbaugC5fkJf57IPLaoG7/fHThURJ 8EjNjCNQUva1njYv6kFkapOTDW82fsbM7fD7TbD6cqWMuWh1dHZFsJUVgrF5VQgqQO 1iehuaju4nI7RgOUdc6w4SDE= Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id CD1CD2D029E0; Tue, 3 Jun 2025 10:08:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 6V-9df7_AJpP; Tue, 3 Jun 2025 10:08:00 +0000 (UTC) Received: from strong-rtwn0.sbone.de (strong-rtwn0.sbone.de [IPv6:fde9:577b:c1a9:4902:3e64:cfff:fe55:bc80]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CB7DF2D029D8; Tue, 3 Jun 2025 10:08:00 +0000 (UTC) Date: Tue, 3 Jun 2025 10:08:00 +0000 (UTC) From: "Bjoern A. Zeeb" To: Steve Kargl cc: freebsd-current@freebsd.org Subject: Re: drm panic after new world In-Reply-To: Message-ID: <5618ns81-p35q-5r56-r305-89210s544182@SerrOFQ.bet> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.81)[-0.810]; DMARC_POLICY_ALLOW(-0.50)[zabbadoz.net,none]; R_DKIM_ALLOW(-0.20)[zabbadoz.net:s=20240622]; R_SPF_ALLOW(-0.20)[+ip6:2003:a:140a:2200:6:594:fffe:19]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[zabbadoz.net:+] X-Rspamd-Queue-Id: 4bBRHP0g4Dz3wxY X-Spamd-Bar: --- On Thu, 29 May 2025, Steve Kargl wrote: > On Thu, May 29, 2025 at 01:06:22PM -0700, Steve Kargl wrote: >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 >> 57 __asm("movq %%gs:%c1,%0" : "=r" (td) >> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 >> td = > > (snip) > >> #5 0xffffffff805c8718 in pfs_add_node ( >> parent=parent@entry=0xfffff80003955400, pn=pn@entry=0xfffff803557e0900) >> at /usr/src/sys/fs/pseudofs/pseudofs.c:123 >> iter = > > This is hitting a KASSERT under the INVARIANTS option. Yes, and once again pretty useless information. I am adding name and type to it so we get better ideas right away just from the panic string. Thankfully the name is not optimized out in frame #7: 'radeon_ring_gfx' >> #6 0xffffffff805c8bd2 in pfs_create_file (parent=0xfffff80003955400, >> name=name@entry=0xffffffff82b293f4 "radeon_ring_gfx", >> fill=0xffffffff82bf70f0 , >> attr=0xffffffff82bf72f0 , vis=vis@entry=0x0, >> destroy=0xffffffff82bf7310 , flags=33) >> at /usr/src/sys/fs/pseudofs/pseudofs.c:266 >> pn = 0xfffff803557e0900 >> #7 0xffffffff82bf70b8 in debugfs_create_file ( >> name=0xffffffff82b293f4 "radeon_ring_gfx", mode=292, >> parent=0xfffff8000398e400, data=0xfffffe012354dd30, >> fops=0xffffffff82b55918 ) >> at /usr/src/sys/compat/lindebugfs/lindebugfs.c:209 There were changes to that adding a new function or using __func__ in the timeframe you mention. But could also be that CONFIG_DEBUG_FS was turned on somewhere which was not before or it's because you are running a debug kernel instaed of a no-debug? >> dm = 0xfffff80003990580 >> dnode = 0xfffff80003990580 >> pnode = >> flags = >> _size = >> _malloc_item = >> #8 0xffffffff82ad0084 in radeon_ring_init () from /boot/modules/radeonkms.ko >> No symbol table info available. > > How does one get kernel debugging symbols into radeonkms.ko? I think if you do the buildkernel/installkernel with LOCAL_MODULES_DIR=/path/to/drm/sources they are likely to be there in the right place. I don't know how this works with ports but also not my area of expertise. Looking at 6.6 sources: My suspicion is given the path is reset/resume and that calls radeon_ring_init() for the RADEON_RING_TYPE_GFX_INDEX, that the original init path likely did the same but no one cleaned things up. #8 0xffffffff82ad0084 in radeon_ring_init () from /boot/modules/radeonkms.ko #9 0xffffffff82a5caf7 in evergreen_startup () from /boot/modules/radeonkms.ko #10 0xffffffff82a5b333 in evergreen_resume () from /boot/modules/radeonkms.ko #11 0xffffffff82ab3e90 in radeon_gpu_reset () from /boot/modules/radeonkms.ko The evergreen_startup() function doing the call .. 5083 ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX]; 5084 r = radeon_ring_init(rdev, ring, ring->ring_size, RADEON_WB_CP_RPTR_OFFSET, 5085 RADEON_CP_PACKET2); .. is called from evergreen_resume() and evergreen_init(). Would be interesting to know when and how often you pass these functions during boot before panic. You could try adding a dump_stack() there and the message buffer from the core file should likely tell us: % git diff diff --git drivers/gpu/drm/radeon/evergreen.c drivers/gpu/drm/radeon/evergreen.c index eedb7dec0f..a6ae0cd9c4 100644 --- drivers/gpu/drm/radeon/evergreen.c +++ drivers/gpu/drm/radeon/evergreen.c @@ -5080,6 +5080,8 @@ static int evergreen_startup(struct radeon_device *rdev) } evergreen_irq_set(rdev); + dump_stack(); + ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX]; r = radeon_ring_init(rdev, ring, ring->ring_size, RADEON_WB_CP_RPTR_OFFSET, RADEON_CP_PACKET2); -- Bjoern A. Zeeb r15:7