lkml.org 
[lkml]   [2022]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation
Date
On Thu, 20 Oct 2022, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
>> > hi Greg, Dan, Jason, DRM-folk,
>> >
>> > heres follow-up to V6:
>> > rebased on driver-core/driver-core-next for -v6 applied bits (thanks)
>> > rework drm_debug_enabled{_raw,_instrumented,} per Dan.
>> >
>> > It excludes:
>> > nouveau parts (immature)
>> > tracefs parts (I missed --to=Steve on v6)
>> > split _ddebug_site and de-duplicate experiment (way unready)
>> >
>> > IOW, its the remaining commits of V6 on which Dan gave his Reviewed-by.
>> >
>> > If these are good to apply, I'll rebase and repost the rest separately.
>>
>> All now queued up, thanks.
>
> This stuff broke i915 debugs. When I first load i915 no debug prints are
> produced. If I then go fiddle around in /sys/module/drm/parameters/debug
> the debug prints start to suddenly work.

Wait what? I always assumed the default behaviour would stay the same,
which is usually how we roll. It's a regression in my books. We've got a
CI farm that's not very helpful in terms of dmesg logging right now
because of this.

BR,
Jani.


--
Jani Nikula, Intel Open Source Graphics Center

\
 
 \ /
  Last update: 2022-10-21 11:19    [W:0.090 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site