Re: [linux-next:master] BUILD REGRESSION ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f

Is there something new since the last report? https://lore.kernel.org/all/202406060125.8ggeepjs-...@intel.com/ If not, can we please not keep spamming, as it makes it harder to know what to fix and what has been fixed. -- Steve On Fri, 07 Jun 2024 01:15:11 +0800 kernel test robot wrote:

Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

On Tue, 04 Jun 2024 10:45:37 +0300 Jani Nikula wrote: > On Sun, 02 Jun 2024, Andy Shevchenko > wrote: > > Make two APIs look similar. Hence convert match_string() to be > > a 2-argument macro. In order to avoid unneeded churn, convert > > all users as well. There is no functional change

Re: [PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 17 May 2024 10:36:37 -0700 Guenter Roeck wrote: > Building csky:allmodconfig (and others) ... failed > -- > Error log: > In file included from include/trace/trace_events.h:419, > from include/trace/define_trace.h:102, > from

Re: [PATCH 05/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

On Wed, 10 Apr 2024 13:08:57 +0200 Sebastian Andrzej Siewior wrote: > On 2024-04-09 11:55:33 [-0400], Steven Rostedt wrote: > > I believe you need to do it in the .c file: > > > > Can you try something like this? > > > … > > ? > > I tried and n

Re: [PATCH 05/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

On Tue, 9 Apr 2024 13:06:01 +0200 Sebastian Andrzej Siewior wrote: > among a few other things I was not aware of. > So yes, this patch is not needed since it makes no difference but I still > have trace points I would rather not have. > If you a clue how to deal with this properly, I am all

Re: [PATCH 05/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

> behind DRM_I915_LOW_LEVEL_TRACEPOINTS. The NOTRACE should not be included in the individual trace files. Can you show where this is an issue. I think this is fixing the symptom and not the bug itself. -- Steve > > Cc: Steven Rostedt > Signed-off-by: Sebastian Andrzej Siewior &g

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Thu, 14 Mar 2024 09:57:57 -0700 Alison Schofield wrote: > On Fri, Feb 23, 2024 at 12:56:34PM -0500, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in >

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 13:46:53 -0500 Steven Rostedt wrote: > Now one thing I could do is to not remove the parameter, but just add: > > WARN_ON_ONCE((src) != __data_offsets->item##_ptr_); > > in the __assign_str() macro to make sure that it's still the same that is &

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 14:50:49 -0500 Kent Overstreet wrote: > Tangentially related though, what would make me really happy is if we > could create the string with in the TP__fast_assign() section. I have to > have a bunch of annoying wrappers right now because the string length > has to be known

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 10:30:45 -0800 Jeff Johnson wrote: > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in > >the second

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

On Fri, 23 Feb 2024 12:56:34 -0500 Steven Rostedt wrote: > Note, the same updates will need to be done for: > > __assign_str_len() > __assign_rel_str() > __assign_rel_str_len() Correction: The below macros do not pass in their source to the entry macros, so the

Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code

On Thu, 22 Feb 2024 14:04:20 -0500 Rodrigo Vivi wrote: > > Note, I have patches that depend on this fix, so if one of the maintainers > > would like to just give me an "Acked-by", I'll take it through my tree. I > > doubt it will have any conflicts, unless you are planning on changing the > >

Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code

On Thu, 22 Feb 2024 20:42:59 +0200 Ville Syrjälä wrote: > On Thu, Feb 22, 2024 at 01:30:57PM -0500, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > I'm working on improving the __assign_str() and __string() macros to be > > more efficient,

Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code

On Thu, 22 Feb 2024 13:30:57 -0500 Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > I'm working on improving the __assign_str() and __string() macros to be > more efficient, and removed some unneeded semicolons. This triggered a bug > in the build as

[PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code

From: "Steven Rostedt (Google)" I'm working on improving the __assign_str() and __string() macros to be more efficient, and removed some unneeded semicolons. This triggered a bug in the build as some of the __assign_str() macros in intel_display_trace was missing a terminating semicol

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 20:21:33 -0400 Steven Rostedt wrote: > On Wed, 15 Mar 2023 16:20:11 -0400 > Steven Rostedt wrote: > > > On Wed, 15 Mar 2023 20:51:49 +0100 > > Christian König wrote: > > > > > Steven please try the attached patch. > >

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 16:20:11 -0400 Steven Rostedt wrote: > On Wed, 15 Mar 2023 20:51:49 +0100 > Christian König wrote: > > > Steven please try the attached patch. > > I applied it, but as it's not always reproducible, I'll have to give it > several runs before I giv

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 20:51:49 +0100 Christian König wrote: > Steven please try the attached patch. I applied it, but as it's not always reproducible, I'll have to give it several runs before I give you my "tested-by" tag. -- Steve

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 11:57:12 -0400 Steven Rostedt wrote: > The WARN_ON triggered: > > [ 21.481449] mpls_gso: MPLS GSO support > [ 21.488795] IPI shorthand broadcast: enabled > [ 21.488873] [ cut here ] > [ 21.490101]

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 11:57:12 -0400 Steven Rostedt wrote: So I'm looking at the backtraces. > The WARN_ON triggered: > > [ 21.481449] mpls_gso: MPLS GSO support > [ 21.488795] IPI shorthand broadcast: enabled > [ 21.488873] [ cut here ]

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Wed, 15 Mar 2023 16:25:11 +0100 Christian König wrote: > >> > >> Thanks for the notice, > > I'm still getting this on Linus's latest tree. > > This must be some reference counting issue which only happens in your > particular use case. We have tested this quite extensively and couldn't

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

On Tue, 7 Mar 2023 21:22:23 -0500 Steven Rostedt wrote: > Looks like there was a lock possibly used after free. But as commit > 9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup > workers") changed a lot of this code, I figured it may be the culprit. If

[Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

In a report for a regression in my code, I tried to run v6.3-rc1 through my tests. It crashed at boot up on my first test (my start up tests do take a long time, hence the 206 seconds of boot!). [ 206.238782] [ cut here ] [ 206.277786] DEBUG_LOCKS_WARN_ON(lock->magic

Re: [Intel-gfx] [PATCH] treewide: Convert del_timer*() to timer_shutdown*()

On Tue, 20 Dec 2022 13:45:19 -0500 Steven Rostedt wrote: > [ > Linus, > > I ran the script against your latest master branch: > commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf > > As the timer_shutdown*() code is now in your tree, I figured >

[Intel-gfx] [PATCH] treewide: Convert del_timer*() to timer_shutdown*()

applied at the end of the merge window, to avoid conflicts with linux-next during the development cycle. I can wait to Friday to run it again, and resubmit. What is the best way to handle this? ] From: "Steven Rostedt (Google)" Due to several bugs caused by timers bein

[Intel-gfx] [GIT PULL] treewide: timers: Use timer_shutdown*() before freeing timers

Tag SHA1: 7685328352dfd2908e23048f563e328dbd3526e9 Head SHA1: 870556da63870e01ade9bb8418ac5a21862f2f10 Steven Rostedt (Google) (5): ARM: spear: Do not use timer namespace for timer_shutdown() function clocksource/drivers/arm_arch_timer: Do not use timer namespace for timer_shutdown() function clocksour

[Intel-gfx] [PATCH v6a 0/5] timers: Use timer_shutdown*() before freeing timers

- Updated the script to make ptr and slab into expressions instead of using identifiers (Julia Lawall and Linus Torvalds) Steven Rostedt (Google) (5): ARM: spear: Do not use timer namespace for timer_shutdown() function clocksource/drivers/arm_arch_timer: Do not use timer

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 14:13:14 -0700 Linus Torvalds wrote: > (Comparing output is also fun because the ordering of the patches is > random, so consecutive runs with the same rule will give different > patches. I assume that it's just because it's done in parallel, but it > doesn't help the "try to

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 14:13:14 -0700 Linus Torvalds wrote: > And trying "when != ptr->timer" actually does the right thing in that > it gets rid of the case where the timer is modified outside of the > del_timer() case, *but* it also causes odd other changes to the > output. > > Look at what it

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 14:03:56 -0400 Steven Rostedt wrote: > --- a/drivers/isdn/hardware/mISDN/hfcmulti.c > +++ b/drivers/isdn/hardware/mISDN/hfcmulti.c > @@ -4544,7 +4544,7 @@ release_port(struct hfc_multi *hc, struct dchannel *dch) > spin_lock_irqsave(>lock, flags); >

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 12:36:42 -0400 Steven Rostedt wrote: > --8< > @@ > identifier ptr, timer, rfield, slab; > @@ > ( > - del_timer(>timer); > + timer_shutdown(>timer); > | > - del_timer_sync(>tim

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 08:59:36 -0700 Linus Torvalds wrote: > Others in the series were *definitely* not scripted, doing clearly > manual cleanups: > > -if (dch->timer.function) { > -del_timer(>timer); > -dch->timer.function = NULL; > -} > +timer_shutdown(>timer); > >

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 12:36:42 -0400 Steven Rostedt wrote: > On Sat, 5 Nov 2022 08:59:36 -0700 > Linus Torvalds wrote: > > > On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote: > > > > > > > > Patch 1 fixes an issue with sunrpc/xprt where it incorrect

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 08:59:36 -0700 Linus Torvalds wrote: > On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote: > > > > Patch 1 fixes an issue with sunrpc/xprt where it incorrectly uses > > del_singleshot_timer_sync() for something that is not a oneshot timer. As > >

Re: [Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

On Sat, 5 Nov 2022 07:18:17 -0700 Guenter Roeck wrote: > Just in case you didn't notice: > > Looking through the resulting code, I think some of the remaining > calls to del_singleshot_timer_sync() can be converted as well. > > The calls in

[Intel-gfx] [PATCH v4a 11/38] timers: drm: Use timer_shutdown_sync() before freeing timer

From: "Steven Rostedt (Google)" Before a timer is freed, timer_shutdown_sync() must be called. Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodr

[Intel-gfx] [PATCH v4a 31/38] timers: drm: Use timer_shutdown_sync() for on stack timers

From: "Steven Rostedt (Google)" Before a timer is released, timer_shutdown_sync() must be called. Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v4a 00/38] timers: Use timer_shutdown*() before freeing timers

at they are all safe, but that's just my own opinion. This series is here: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git timers-start Head SHA1: f58b516a65bac76f1bfa00126856d6c6c3d24a40 Steven Rostedt (Google) (38): SUNRPC/xprt: Use del_timer_sync() instead of del_s

Re: [Intel-gfx] [RFC][PATCH v3 00/33] timers: Use timer_shutdown*() before freeing timers

On Fri, 4 Nov 2022 15:42:09 -0400 Steven Rostedt wrote: > $ git grep '\btimer_shutdown' > arch/arm/mach-spear/time.c:static inline void timer_shutdown(struct > clock_event_device *evt) > arch/arm/mach-spear/time.c: timer_shutdown(evt); > arch/arm/mach-spear/time.c: tim

Re: [Intel-gfx] [RFC][PATCH v3 00/33] timers: Use timer_shutdown*() before freeing timers

On Fri, 4 Nov 2022 12:22:32 -0700 Guenter Roeck wrote: > Unfortunately the renaming caused some symbol conflicts. > > Global definition: timer_shutdown > > File Line > 0 time.c93 static inline void timer_shutdown(struct > clock_event_device *evt) > 1 arm_arch_timer.c

Re: [Intel-gfx] [RFC][PATCH v3 13/33] timers: drm: Use timer_shutdown_sync() before freeing timer

On Fri, 4 Nov 2022 08:48:28 + Tvrtko Ursulin wrote: > If it stays all DRM drivers in one patch then I guess it needs to go via > drm-misc, which for i915 would be okay I think in this case since patch > is extremely unlikely to clash with anything. Or split it up per driver > and then we

Re: [Intel-gfx] [RFC][PATCH v3 13/33] timers: drm: Use timer_shutdown_sync() before freeing timer

[ Once again, quilt fails the MIME coding ] From: "Steven Rostedt (Google)" Before a timer is freed, timer_shutdown_sync() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vet

[Intel-gfx] [RFC][PATCH v3 00/33] timers: Use timer_shutdown*() before freeing timers

t deactivates the timer. - Added a few more locations that got converted. git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace/timers Head SHA1: 25106f0bb7968b3e8c746a7853f44b51840746c3 Steven Rostedt (Google) (33): timers: Add timer_shutdown_sync() and timer_shutdown()

[Intel-gfx] [RFC][PATCH v3 13/33] timers: drm: Use timer_shutdown_sync() before freeing timer

From: "Steven Rostedt (Google)" Before a timer is freed, timer_shutdown_sync() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen

Re: [Intel-gfx] [RFC][PATCH v2 13/31] timers: drm: Use del_timer_shutdown() before freeing timer

[ quilt mail --send still can't handle unicode characters. Here's the patch again ] From: "Steven Rostedt (Google)" Before a timer is freed, del_timer_shutdown() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trøn

[Intel-gfx] [RFC][PATCH v2 13/31] timers: drm: Use del_timer_shutdown() before freeing timer

From: "Steven Rostedt (Google)" Before a timer is freed, del_timer_shutdown() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v2 26/27] dyndbg: 4 new trace-events: pr_debug, dev_dbg, drm_{, dev}debug

Sorry for the late review. I finally got some time to look at this. On Mon, 16 May 2022 16:56:39 -0600 Jim Cromie wrote: > diff --git a/include/trace/events/drm.h b/include/trace/events/drm.h > new file mode 100644 > index ..6de80dd68620 > --- /dev/null > +++

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef

On Wed, 09 Feb 2022 15:49:01 +0200 Jani Nikula wrote: > > Because I want to use the lockdep annotation for other purposes. > > But the workqueue lockdep_map was defined under LOCKDEP > > only. Please see the description in the cover letter. > > > >

Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

grant_log == TOMOYO_GRANTLOG_YES is not readable at all. Not compared to cond->grant_log == TOMOYO_GRANTLOG_YES I say keep it one line! Reviewed-by: Steven Rostedt (Google) -- Steve > > Then, > > Reviewed-by: Sakari Ailus

Re: [Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

On Wed, 19 Jan 2022 11:15:08 +0200 Andy Shevchenko wrote: > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } > > > > Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others > (enable/disable) it will not be possible to keep on one line. And hence >

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Disable tracing points on PREEMPT_RT

On Tue, 14 Dec 2021 18:34:50 +0200 Ville Syrjälä wrote: > Looks lightly tedious. Can't we have "slow" (or whatever) versions of > the trace macros so we could just declare these the same was as before > without having to manually write that wrapper for every event? That would be quite tedious

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Disable tracing points on PREEMPT_RT

On Tue, 14 Dec 2021 15:03:00 +0100 Sebastian Andrzej Siewior wrote: > Luca Abeni reported this: > | BUG: scheduling while atomic: kworker/u8:2/15203/0x0003 > | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 > | Call Trace: > | rt_spin_lock+0x3f/0x50 > |

Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 19 Nov 2021 15:46:31 -0700 jim.cro...@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out'

Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 12 Nov 2021 12:32:23 -0500 Jason Baron wrote: > Ok, it looks like Vincent's patch defines a dyndbg event and then uses > 'trace_dyndbg()' to output to the 'main' log. So all dynamic output to > the 'main' ftrace buffer goes through that event if I understand it > correctly. Here's a

Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

On Fri, 12 Nov 2021 10:08:41 -0500 Jason Baron wrote: > > A key difference between that patchset and this patch (besides that > > small fact that I used +x instead of +T) was that my patchset allowed > > the dyndbg trace to be emitted to the main buffer and did not force them > > to be in an

Re: [Intel-gfx] [PATCH v0 00/42] notifiers: Return an error when callback is already registered

On Mon, 8 Nov 2021 15:35:50 +0100 Borislav Petkov wrote: > On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote: > > I guess I can add another indirection to notifier_chain_register() and > > avoid touching all the call sites. > > IOW, something like this below. > > This way I

Re: [Intel-gfx] [BUG 5.15-rc3] kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!

;__i915_sw_fence_call" I discovered afterwards; and > ignoring recent discussions of where __attributes ought to appear :-) > > > [PATCH] drm/i915: fix blank screen booting crashes Thanks, I added it to my "fixes" patch set that I apply before testing. It looks to have don

[Intel-gfx] [BUG 5.15-rc3] kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!

When I tried to test patches applied to v5.15-rc3, I hit this bug (and hence can not test my code), on 32 bit x86. [ cut here ] kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! invalid opcode: [#1] SMP PTI CPU: 3 PID: 1 Comm: swapper/0 Not tainted

Re: [Intel-gfx] [PATCH 0/4] drm/i915: Silence pipe tracepoint WARNs

On Thu, 4 Mar 2021 19:04:17 +0200 Ville Syrjala wrote: > From: Ville Syrjälä > > I believe this should silence the WARN spew from the > pipe disable tracepoint Steve reported. And I tossed in > a few other minor improvements as well. > > Cc: Steven Rostedt It s

Re: [Intel-gfx] [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint

On Mon, 1 Mar 2021 19:20:59 +0200 Ville Syrjälä wrote: > > ilk_crtc_disable+0x85/0x390 [i915] > > But this part is confusing me. intel_crtc_get_vblank_counter() is > only supposed to do drm_crtc_accurate_vblank_count() fallback when > the hardware lacks a working frame counter, and that

[Intel-gfx] [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint

On my test box with latest v5.12-rc1, running with all trace events enabled, I consistently trigger this warning. It appears to get triggered by the trace_intel_pipe_disable() code. -- Steve [ cut here ] i915 :00:02.0:

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

On Fri, 15 Jan 2021 09:50:25 +0200 Jani Nikula wrote: > >> fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c > >> ("drm/i915: Shut down displays gracefully on reboot") > >> > >> Which makes sense, as it happens on shutdown. > > Please try this pull, heading to -rc4, which cointains "drm/i915: >

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

On Thu, 14 Jan 2021 20:15:45 -0800 Linus Torvalds wrote: > On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote: > > > > Thanks, I take it, it will be going into mainline soon. > > Just got merged - it might be a good idea to verify that your problem is > solved

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

On Thu, 14 Jan 2021 21:35:53 + Chris Wilson wrote: > Quoting Steven Rostedt (2021-01-14 21:32:06) > > On reboot, one of my test boxes now triggers the following warning: > > 057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver > shutdown"

Re: [Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

[ Forgot to add those on the commit itself ] -- Steve On Thu, 14 Jan 2021 16:32:06 -0500 Steven Rostedt wrote: > On reboot, one of my test boxes now triggers the following warning: > > [ cut here ] > RPM raw-wakeref not held > WARNING: CPU: 4 PI

[Intel-gfx] [BUG] on reboot: bisected to: drm/i915: Shut down displays gracefully on reboot

On reboot, one of my test boxes now triggers the following warning: [ cut here ] RPM raw-wakeref not held WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106 gen6_write32+0x1bc/0x2a0 [i915] Modules linked in: ebtable_filter ebtables bridge stp llc

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 19:55:10 +0200 Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > > On Thu, 24 Sep 2020 08:57:52 +0200 > > Thomas Gleixner wrote: > > > >> > Now as for migration disabled nesting, at least now we would have >

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 14:42:41 +0200 Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > > Anyway, instead of blocking. What about having a counter of number of > > migrate disabled tasks per cpu, and when taking a migrate_disable(), a

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 08:57:52 +0200 Thomas Gleixner wrote: > > Now as for migration disabled nesting, at least now we would have > > groupings of this, and perhaps the theorists can handle that. I mean, > > how is this much different that having a bunch of tasks blocked on a > > mutex with the

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, 23 Sep 2020 22:55:54 +0200 Thomas Gleixner wrote: > > Perhaps make migrate_disable() an anonymous local_lock()? > > > > This should lower the SHC in theory, if you can't have stacked migrate > > disables on the same CPU. > > I'm pretty sure this ends up in locking hell pretty fast and

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, 23 Sep 2020 10:40:32 +0200 pet...@infradead.org wrote: > However, with migrate_disable() we can have each task preempted in a > migrate_disable() region, worse we can stack them all on the _same_ CPU > (super ridiculous odds, sure). And then we end up only able to run one > task, with the

Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

On Mon, 14 Sep 2020 22:42:09 +0200 Thomas Gleixner wrote: > 21 files changed, 23 insertions(+), 92 deletions(-) This alone makes it look promising, and hopefully acceptable by Linus :-) -- Steve ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 1/2] trace: Export anonymous tracing

On Sun, 01 Mar 2020 22:22:25 + Chris Wilson wrote: > Quoting Steven Rostedt (2020-03-01 18:18:16) > > On Sun, 1 Mar 2020 15:52:47 + > > Chris Wilson wrote: > > > > > To facilitate construction of per-client event ringbuffers, in > > > part

Re: [Intel-gfx] [PATCH 1/2] trace: Export anonymous tracing

On Sun, 01 Mar 2020 22:22:25 + Chris Wilson wrote: > > I'm curious to why we need it to be anonymous. Why not allow them to be > > visible from the tracing directory. This could allow for easier > > debugging. Note, the trace instances have ref counters thus they can't > > be removed if

Re: [Intel-gfx] [PATCH 1/2] trace: Export anonymous tracing

ow they work and what they are for. -- Steve > > Signed-off-by: Chris Wilson > Cc: Steven Rostedt (VMware) > --- > include/linux/trace.h | 4 ++ > kernel/trace/trace.c | 142 ++ > 2 file

Re: [Intel-gfx] [PATCH] Make is_signed_type() simpler

On Sun, 29 Sep 2019 23:44:24 +0300 Alexey Dobriyan wrote: > On Sun, Sep 29, 2019 at 04:15:31PM -0400, Steven Rostedt wrote: > > On Sun, 29 Sep 2019 23:06:19 +0300 > > Alexey Dobriyan wrote: > > > > > * Simply compare -1 with 0, > > > * Drop unnecessary

Re: [PATCH] Make is_signed_type() simpler

On Sun, 29 Sep 2019 23:06:19 +0300 Alexey Dobriyan wrote: > * Simply compare -1 with 0, > * Drop unnecessary parenthesis sets > > New macro leaves pointer as "unsigned type" but gives a warning, > which should be fine because asking whether a pointer is signed is > strange question. > > I'm

[Intel-gfx] [PATCH] drm/i915: Copy name string into ring buffer for intel_update/disable_plane tracepoints

From: "Steven Rostedt (VMware)" Currently the intel_update_plane and intel_disable_plane tracepoints record the address of plane->name in the ring buffer, and then when reading the ring buffer uses %s to get the name. The issue with this, is that those two events can be minutes,

Re: [Intel-gfx] Need to remove char pointers from trace events

On Wed, 10 Jul 2019 18:45:24 +0300 Ville Syrjälä wrote: > > TP_printk("pipe %c, plane %s, frame=%u, scanline=%u", > > pipe_name(__entry->pipe), __entry->name, > > __entry->frame, __entry->scanline) > > > > > > The issue here is that you record a

[Intel-gfx] Need to remove char pointers from trace events

I was doing a bit of an audit on trace events and found this: # cat /debug/tracing/events/i915/intel_disable_plane/format name: intel_disable_plane ID: 1358 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags;

Re: [Intel-gfx] [patch V2 23/29] tracing: Simplify stack trace retrieval

On Thu, 18 Apr 2019 10:41:42 +0200 Thomas Gleixner wrote: > Replace the indirection through struct stack_trace by using the storage > array based interfaces. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Reviewed-by: Steven Rostedt (VMw

Re: [Intel-gfx] [patch V2 24/29] tracing: Remove the last struct stack_trace usage

On Thu, 18 Apr 2019 10:41:43 +0200 Thomas Gleixner wrote: > Simplify the stack retrieval code by using the storage array based > interface. > > Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt (VMware) -- Steve ___ Intel

Re: [Intel-gfx] [patch V2 22/29] tracing: Make ftrace_trace_userstack() static and conditional

On Thu, 18 Apr 2019 10:41:41 +0200 Thomas Gleixner wrote: > It's only used in trace.c and there is absolutely no point in compiling it > in when user space stack traces are not supported. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Funny, these were moved out to g

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

On Fri, 19 Apr 2019 00:44:17 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:20 +0200 > > Thomas Gleixner wrote: > > > > > @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab > >

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

o begin with. I think I copied something else that couldn't do it this way for some reason and didn't put any brain power behind the copy. :-/ But that was back in 2008 so I blame it on being "young and stupid" ;-) Other then the above nit and removing the unneeded +1 in max_entri

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 17:24:43 -0400 Steven Rostedt wrote: > I believe it was for historical leftovers (there was a time it was > required), and left there for "paranoid" sake. But let me apply the > patch and see if it is really needed. I removed the +1 on the

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

On Thu, 18 Apr 2019 23:14:45 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > > > On Thu, Apr 18, 2019 at 10:41:20AM +0200, Thomas Gleixner wrote: > > > - Remove the extra array member of stack_dump_trace[]. It's not required > > > as > > > the stack

Re: [Intel-gfx] [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

On Thu, 18 Apr 2019 14:58:55 -0500 Tom Zanussi wrote: > > Tom, > > > > Can you review this too? > > Looks good to me too! > > Acked-by: Tom Zanussi > Would you be OK to upgrade this to a Reviewed-by tag? Thanks! -- Steve ___ Intel-gfx mailing

Re: [Intel-gfx] [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

On Thu, 18 Apr 2019 17:43:59 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 18 Apr 2019, Steven Rostedt wrote: > > On Thu, 18 Apr 2019 10:41:40 +0200 > > Thomas Gleixner wrote: > > > -static DEFINE_PER_CPU(struct ftrace_stack, ftrace_stack); > > > +/*

Re: [Intel-gfx] [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

e cpu buffer > for stack retrieval and avoids the fixed length allocation along with the > conditional execution pathes. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt > --- > kernel/trace/trace.c | 77 > +-- &

Re: [Intel-gfx] [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

[ Added Tom Zanussi ] On Thu, 18 Apr 2019 10:41:39 +0200 Thomas Gleixner wrote: > The indirection through struct stack_trace is not necessary at all. Use the > storage array based interface. > > Signed-off-by: Thomas Gleixner > Cc: Steven Rostedt Looks fine to me Acked-by:

Re: [Intel-gfx] [patch V2 14/29] dm bufio: Simplify stack trace retrieval

On Thu, 18 Apr 2019 14:11:44 +0200 Alexander Potapenko wrote: > On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote: > > > > On Thu, 18 Apr 2019, Alexander Potapenko wrote: > > > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner > > > wrote: > > > > -

Re: [Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig

On Wed, 19 Dec 2018 12:08:18 +0200 Joonas Lahtinen wrote: > To me, it seems almost as if folks are too preoccupied with thinking if > we somehow can do this through tracepoints, to stop and actually think > if we should. Regardless of whether it should or shouldn't, one solution to this is to

Re: [Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig

On Mon, 17 Dec 2018 18:26:03 -0700 Michael Sartain wrote: > Ftrace and perf are fantastic, stable, very well known, and documented with > ecosystems built around them. AMD already is doing exactly what we are asking > for with tracepoints, and Intel has tracepoints that work right now. Please, >

Re: [Intel-gfx] [PATCHv3] lib/ratelimit: Lockless ratelimiting

On Fri, 20 Jul 2018 16:33:36 +0100 Dmitry Safonov wrote: > On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote: > > > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: > > > > > Currently ratelimit_state is protected with spin_lock. If the > > > > > .lock > > > > > is > > > > > taken

Re: [Intel-gfx] [PATCH] trace: Fixup logic inversion on setting trace_global_clock defaults

On Wed, 4 Apr 2018 22:24:50 +0100 Chris Wilson wrote: > In commit 932066a15335 ("tracing: Default to using trace_global_clock if > sched_clock is unstable"), the logic for deciding to override the > default clock if unstable was reversed from the earlier posting. I was

Re: [Intel-gfx] [PATCH v3] trace: Default to using trace_global_clock if sched_clock is unstable

please switch to the trace global clock: >echo global > /sys/kernel/debug/tracing/trace_clock > >Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> >Cc: Steven Rostedt (VMware) <rost...@goodmis.org> >--- >v2: Tell the user what's happening and what they can

Re: [Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

ta way too big! 18446743856563626466 ts=18446744054496180323 write > stamp = 197932553857 > If you just came from a suspend/resume, > please switch to the trace global clock: > echo global > /sys/kernel/debug/tracing/trace_clock > > Signed-off-by: Chris Wilson &l

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Fri, 30 Mar 2018 15:07:53 +0100 Chris Wilson wrote: > Sure, I was mainly floating the idea of trying to pick sensible > defaults. Unstable clocks are quite rare nowadays, the ones we have in > the lab are a pair of Core2 Duo. I still have a box too ;-) I'm not so

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

say: Or set the global clock via the kernel command line with "trace_clock=global" ? -- Steve > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Steven Rostedt (VMware) <rost...@goodmis.org> > --- > kernel/trace/trace.c | 13

  1   2   >