[Bug 287165] drm/pseudofs panic in radeonkms.ko

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287165

Bjoern A. Zeeb <bz@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dumbbell@FreeBSD.org
             Status|New                         |Open

--- Comment #13 from Bjoern A. Zeeb <bz@FreeBSD.org> ---
(In reply to Steve Kargl from comment #12)

So my assumption was correct?  We are going twice through evergreen_startup().


...
drmn0: radeon: using MSI.
[drm] radeon: irq initialized.
#0 0xffffffff808bcdeb at linux_dump_stack+0x1b
#1 0xffffffff82a67adc at evergreen_startup+0x15ec
#2 0xffffffff82a67fb6 at evergreen_init+0x276
#3 0xffffffff82abdc35 at radeon_device_init+0x835
#4 0xffffffff82acebbe at radeon_driver_load_kms+0x19e
#5 0xffffffff82ba4147 at drm_dev_register+0x1c7
#6 0xffffffff82ac4cdc at radeon_pci_probe+0x15c
#7 0xffffffff808c5020 at linux_pci_attach_device+0x440
#8 0xffffffff806ac61a at device_attach+0x3fa
#9 0xffffffff806ae370 at bus_generic_driver_added+0x90
#10 0xffffffff806a9ba9 at devclass_driver_added+0x29
#11 0xffffffff806a9ac8 at devclass_add_driver+0x138
#12 0xffffffff808c5f51 at _linux_pci_register_driver+0xc1
#13 0xffffffff82ac4b4e at radeonkms_evh+0x3e
#14 0xffffffff80652be0 at module_register_init+0xb0
#15 0xffffffff80642e0b at linker_load_module+0xbeb
#16 0xffffffff80644b25 at kern_kldload+0x125
#17 0xffffffff80644bb9 at sys_kldload+0x59
[drm] ring test on 0 succeeded in 4 usecs
[drm] ring test on 3 succeeded in 6 usecs
[drm] ring test on 5 succeeded in 3 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
...
...
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 1024M enabled (table at 0x0000000000162000).
drmn0: WB enabled
drmn0: fence driver on ring 0 use gpu addr 0x0000000040000c00
drmn0: fence driver on ring 3 use gpu addr 0x0000000040000c0c
drmn0: fence driver on ring 5 use gpu addr 0x0000000000072118
#0 0xffffffff808bcdeb at linux_dump_stack+0x1b
#1 0xffffffff82a67adc at evergreen_startup+0x15ec
#2 0xffffffff82a66333 at evergreen_resume+0x63
#3 0xffffffff82abeea0 at radeon_gpu_reset+0x290
#4 0xffffffff82ac9ea8 at radeon_gem_wait_idle_ioctl+0xb8
#5 0xffffffff82bb4f16 at drm_ioctl_kernel+0xc6
#6 0xffffffff82bb528d at drm_ioctl+0x29d
#7 0xffffffff808ba3b1 at linux_file_ioctl+0x301
#8 0xffffffff806e495e at kern_ioctl+0x1de
#9 0xffffffff806e471f at sys_ioctl+0x12f
#10 0xffffffff80a01e4e at amd64_syscall+0x13e
#11 0xffffffff809d4ccb at fast_syscall_common+0xf8
panic: pfs_add_node(): homonymous siblings: 'radeon_ring_gfx' type 5


I am adding dumbbell to Cc:  Someone needs to figure out where in all this the
cleanup does not happen.  I do not see any debugfs_remove*() calls in amdgpu;
there's likely other code paths to get to there (or possibly other KPI
functions which would cleanup the pfs).

The other question I cannot answer yet, is where is CONFIG_DEBUG_FS turned on
for the build so that you hit this code path in first place.
I do not know how the
./kconfig.mk:           DEBUG_FS \
magic works.

It came in with:
---
commit aec60ec819e1d8aa7961be2effef3f6b22741486
Author:     Jake Freeland <jfree@freebsd.org>
AuthorDate: Mon Oct 10 18:13:11 2022 -0500
Commit:     Emmanuel Vadot <manu@bidouilliste.com>
CommitDate: Tue Oct 11 09:43:23 2022 +0200

    Add support for CONFIG_DEBUG_FS build flag
---

Hmmm Ok.  Entirely untested: could you try this patch?

diff --git radeon/Makefile radeon/Makefile
index f731eb961e..788e1fbb77 100644
--- radeon/Makefile
+++ radeon/Makefile
@@ -129,7 +129,7 @@ CFLAGS+= -I${SRCDIR:H}/amd/include

 CFLAGS+= '-DKBUILD_MODNAME="${KMOD}"'
 CFLAGS+= '-DLINUXKPI_PARAM_PREFIX=radeon_' -DDRM_SYSCTL_PARAM_PREFIX=_${KMOD}
-CFLAGS+= ${KCONFIG:C/(.*)/-DCONFIG_\1/}
+CFLAGS+= ${KCONFIG:NDEBUG_FS:C/(.*)/-DCONFIG_\1/}

 CFLAGS.gcc+= -Wno-redundant-decls -Wno-cast-qual -Wno-unused-but-set-variable
\
        -Wno-maybe-uninitialized

-- 
You are receiving this mail because:
You are the assignee for the bug.