All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Jim Cromie <jim.cromie@gmail.com>,
	daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
Date: Fri, 3 Feb 2023 16:08:34 +0100	[thread overview]
Message-ID: <20230203150834.GA2751526@linux.intel.com> (raw)
In-Reply-To: <87a61v14ad.fsf@intel.com>

On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2023, Jim Cromie <jim.cromie@gmail.com> wrote:
> > Hi everyone,
> >
> > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
> > drivers at modprobe.
> 
> I realize we haven't actually addressed the regression in any way yet,
> and any distro enabling DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE will have
> DRM_USE_DYNAMIC_DEBUG=y by default, and we're hitting the issue with
> trying to gather logs from users on v6.1 or later. It hampers debugging
> pretty badly.
> 
> I appreciate the effort in fixing the problem properly here, but we'll
> need a fix that we can backport to stable kernels.
> 
> Maybe just Ville's idea of
> 
>  config DRM_USE_DYNAMIC_DEBUG
>         bool "use dynamic debug to implement drm.debug"
> -       default y
> +       default n
> +       depends on BROKEN
>         depends on DRM
>         depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> 
> but we'll need that as a patch and merged and backported ASAP.

+1 for this

Regards
Stanislaw

WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Jim Cromie <jim.cromie@gmail.com>,
	daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
Date: Fri, 3 Feb 2023 16:08:34 +0100	[thread overview]
Message-ID: <20230203150834.GA2751526@linux.intel.com> (raw)
In-Reply-To: <87a61v14ad.fsf@intel.com>

On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2023, Jim Cromie <jim.cromie@gmail.com> wrote:
> > Hi everyone,
> >
> > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
> > drivers at modprobe.
> 
> I realize we haven't actually addressed the regression in any way yet,
> and any distro enabling DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE will have
> DRM_USE_DYNAMIC_DEBUG=y by default, and we're hitting the issue with
> trying to gather logs from users on v6.1 or later. It hampers debugging
> pretty badly.
> 
> I appreciate the effort in fixing the problem properly here, but we'll
> need a fix that we can backport to stable kernels.
> 
> Maybe just Ville's idea of
> 
>  config DRM_USE_DYNAMIC_DEBUG
>         bool "use dynamic debug to implement drm.debug"
> -       default y
> +       default n
> +       depends on BROKEN
>         depends on DRM
>         depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> 
> but we'll need that as a patch and merged and backported ASAP.

+1 for this

Regards
Stanislaw

WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
Date: Fri, 3 Feb 2023 16:08:34 +0100	[thread overview]
Message-ID: <20230203150834.GA2751526@linux.intel.com> (raw)
In-Reply-To: <87a61v14ad.fsf@intel.com>

On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2023, Jim Cromie <jim.cromie@gmail.com> wrote:
> > Hi everyone,
> >
> > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
> > drivers at modprobe.
> 
> I realize we haven't actually addressed the regression in any way yet,
> and any distro enabling DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE will have
> DRM_USE_DYNAMIC_DEBUG=y by default, and we're hitting the issue with
> trying to gather logs from users on v6.1 or later. It hampers debugging
> pretty badly.
> 
> I appreciate the effort in fixing the problem properly here, but we'll
> need a fix that we can backport to stable kernels.
> 
> Maybe just Ville's idea of
> 
>  config DRM_USE_DYNAMIC_DEBUG
>         bool "use dynamic debug to implement drm.debug"
> -       default y
> +       default n
> +       depends on BROKEN
>         depends on DRM
>         depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> 
> but we'll need that as a patch and merged and backported ASAP.

+1 for this

Regards
Stanislaw

WARNING: multiple messages have this Message-ID (diff)
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Jim Cromie <jim.cromie@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, daniel.vetter@ffwll.ch,
	seanpaul@chromium.org, Thomas Zimmermann <tzimmermann@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
Date: Fri, 3 Feb 2023 16:08:34 +0100	[thread overview]
Message-ID: <20230203150834.GA2751526@linux.intel.com> (raw)
In-Reply-To: <87a61v14ad.fsf@intel.com>

On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2023, Jim Cromie <jim.cromie@gmail.com> wrote:
> > Hi everyone,
> >
> > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
> > drivers at modprobe.
> 
> I realize we haven't actually addressed the regression in any way yet,
> and any distro enabling DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE will have
> DRM_USE_DYNAMIC_DEBUG=y by default, and we're hitting the issue with
> trying to gather logs from users on v6.1 or later. It hampers debugging
> pretty badly.
> 
> I appreciate the effort in fixing the problem properly here, but we'll
> need a fix that we can backport to stable kernels.
> 
> Maybe just Ville's idea of
> 
>  config DRM_USE_DYNAMIC_DEBUG
>         bool "use dynamic debug to implement drm.debug"
> -       default y
> +       default n
> +       depends on BROKEN
>         depends on DRM
>         depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> 
> but we'll need that as a patch and merged and backported ASAP.

+1 for this

Regards
Stanislaw

  reply	other threads:[~2023-02-03 15:09 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 20:37 [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression Jim Cromie
2023-01-25 20:37 ` Jim Cromie
2023-01-25 20:37 ` Jim Cromie
2023-01-25 20:37 ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 01/19] test-dyndbg: fixup CLASSMAP usage error Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 02/19] test-dyndbg: show that DEBUG enables prdbgs at compiletime Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 03/19] dyndbg: replace classmap list with a vector Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 04/19] dyndbg: make ddebug_apply_class_bitmap more selective Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 05/19] dyndbg: split param_set_dyndbg_classes to inner/outer fns Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 06/19] dyndbg: drop NUM_TYPE_ARRAY Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 07/19] dyndbg: reduce verbose/debug clutter Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 08/19] dyndbg: tighten ddebug_class_name() 1st arg Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 09/19] dyndbg: constify ddebug_apply_class_bitmap args Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 10/19] dyndbg-API: split DECLARE_(DYNDBG_CLASSMAP) to $1(_DEFINE|_USE) Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 11/19] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE) Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 12/19] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 13/19] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 14/19] drm_print: fix stale macro-name in comment Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-02-11 19:24   ` jim.cromie
2023-02-11 19:24     ` jim.cromie
2023-02-11 19:24     ` jim.cromie
2023-02-11 19:24     ` [Intel-gfx] " jim.cromie
2023-01-25 20:37 ` [PATCH v3 15/19] test-dyndbg: build test_dynamic_debug_submod Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 16/19] test-dyndbg: rename DD_SYS_WRAP to DYNDBG_CLASSMAP_PARAM Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 17/19] test-dyndbg: disable WIP dyndbg-trace params Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 18/19] test-dyndbg: tune sub-module behavior Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-25 20:37 ` [PATCH v3 19/19] jump_label: RFC / temporary for CI - tolerate toggled state Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` Jim Cromie
2023-01-25 20:37   ` [Intel-gfx] " Jim Cromie
2023-01-26  2:39 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG regression Patchwork
2023-01-26  2:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-26 13:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-02-03  9:34 ` [PATCH v3 00/19] " Jani Nikula
2023-02-03  9:34   ` Jani Nikula
2023-02-03  9:34   ` Jani Nikula
2023-02-03  9:34   ` [Intel-gfx] " Jani Nikula
2023-02-03 15:08   ` Stanislaw Gruszka [this message]
2023-02-03 15:08     ` Stanislaw Gruszka
2023-02-03 15:08     ` Stanislaw Gruszka
2023-02-03 15:08     ` [Intel-gfx] " Stanislaw Gruszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230203150834.GA2751526@linux.intel.com \
    --to=stanislaw.gruszka@linux.intel.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jim.cromie@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.