drm.debug-on-dyndbg has a regression, due to a chicken-egg initialization problem: 1- modprobe i915 i915 needs drm.ko, which is loaded 1st 2- "modprobe drm drm.debug=0x1ff" (virtual/implied) drm.debug is set post-initialization, from boot-args etc 3- `modprobe i915` finishes W/O drm.debug-on-dyndbg that just works, because all drm_dbg* callsites use drm_debug_enabled() to check __drm_debug & DEM_UT_<CAT> before printing. But the whole point of drm.debug-on-dyndbg is to avoid that runtime test, by enabling (at post-modinit) a static-key at each callsite in the just-loaded module. And since drm.ko is loaded before all dependent modules, none are "just-loaded", and no drm.debug callsites are present yet, except those in drm.ko itself. Signed-off-by: Jim Cromie <jim.cromie@xxxxxxxxx> --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 34f5a092c99e..0d1e59e6bb7e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -54,6 +54,7 @@ config DRM_DEBUG_MM config DRM_USE_DYNAMIC_DEBUG bool "use dynamic debug to implement drm.debug" default y + depends on BROKEN # chicken-egg initial enable problem depends on DRM depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE depends on JUMP_LABEL -- 2.38.1
