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
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
>
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
&
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
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
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
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
> >
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,
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
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
On Fri, 16 Feb 2024 17:37:23 +0100
Daniel Vetter wrote:
> > > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > > drm_mode_object_put(obj);
> > > }
> > >
> > > + if (trace_drm_mode_atomic_commit_enabled()) {
> > > + struct drm_crtc_state
On Fri, 16 Feb 2024 16:09:55 +0100
Pierre-Eric Pelloux-Prayer wrote:
>
> Signed-off-by: Pierre-Eric Pelloux-Prayer
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 21 +
> drivers/gpu/drm/drm_trace.h | 23 +++
> 2 files changed, 44 insertions(+)
>
>
On Wed, 14 Feb 2024 13:00:16 +0100
Christian König wrote:
> > +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
>
> For a single event you should probably use TRACE_EVENT() instead of
> declaring a class. A class is only used if you have multiple events with
> the same parameters.
FYI,
On Tue, 13 Feb 2024 16:50:31 +0100
Pierre-Eric Pelloux-Prayer wrote:
> @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> drm_mode_object_put(obj);
> }
>
> + if (trace_drm_mode_atomic_commit_enabled()) {
> + struct drm_crtc_state
On Tue, 23 Jan 2024 10:43:04 +0100
Christian König wrote:
> While applying the fix a week ago I was under the impression that QXL
> doesn't use a device structure because it doesn't have one and so can't
> give anything meaningful for this parameter.
>
> If QXL does have a device structure
layed_delete worker closer")
> Reported-by: Steven Rostedt
My tests seem to get past the crash with this patch and not my "fix".
Tested-by: Steven Rostedt (Google)
-- Steve
> Cc: Rajneesh Bhardwaj
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/qxl/qxl_tt
On Tue, 23 Jan 2024 12:32:39 +1000
Dave Airlie wrote:
> On Tue, 23 Jan 2024 at 12:21, Dave Airlie wrote:
> >
> > On Tue, 23 Jan 2024 at 12:15, Steven Rostedt wrote:
> > >
> > > On Mon, 22 Jan 2024 19:56:08 -0500
> > > "Bhardwaj, Rajneesh"
On Mon, 22 Jan 2024 19:56:08 -0500
"Bhardwaj, Rajneesh" wrote:
>
> On 1/22/2024 7:43 PM, Linus Torvalds wrote:
> > On Mon, 22 Jan 2024 at 15:17, Steven Rostedt wrote:
> >> Perhaps this is the real fix?
> > If you send a signed-off version, I'll apply
On Mon, 22 Jan 2024 19:29:41 -0500
"Bhardwaj, Rajneesh" wrote:
>
> In one of my previous revisions of this patch when I was experimenting,
> I used something like below. Wonder if that could work in your case
> and/or in general.
>
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
>
On Mon, 22 Jan 2024 18:15:47 -0500
Steven Rostedt wrote:
> > ttm_pool_init(>pool, dev, dev_to_node(dev), use_dma_alloc,
> > use_dma32); <<<--- BUG!
> >
> > Specifically, it appears that dev is NULL and dev_to_node() doesn't like
> > having a N
On Mon, 22 Jan 2024 18:06:05 -0500
Steven Rostedt wrote:
> qxl_ttm_init+0x34/0x130
>
> int ttm_device_init(struct ttm_device *bdev, const struct ttm_device_funcs
> *funcs,
> struct device *dev, struct address_space *mapping,
>
I just kicked off testing some patches on top of 6.8-rc1 and triggered this
immediately:
[ note this happened on both my 32 bit an 64 bit test machines, this is
just the 32 bit output ]
BUG: kernel NULL pointer dereference, address: 0238
#PF: supervisor read access in kernel mode
#PF:
On Wed, 8 Nov 2023 13:55:21 +0800
kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 305230142ae0637213bf6e04f6d9f10bbcb74af8
> commit: c0a581d7126c0bbc96163276f585fd7b4e4d8d0e tracing: Disable interrupt
> or preemption
On Thu, 12 Oct 2023 11:53:52 +0200
Daniel Vetter wrote:
> > You said that turning the kernel ring buffer contents into strings is a
> > very heavy operation, so it is not possible to push this scope
> > separation to userspace, right?
>
> I think it's the kernel that does the formatting, but
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.
> >
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
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
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]
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 ]
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
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
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
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
>
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
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
- 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
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
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
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);
>
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
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);
>
>
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
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
> >
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
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: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedeskt
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
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
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
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
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
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
On Fri, 4 Nov 2022 08:15:53 +0100
Christian König wrote:
> > index fb6e0a6ae2c9..5d3e7b503501 100644
> > --- a/drivers/dma-buf/st-dma-fence.c
> > +++ b/drivers/dma-buf/st-dma-fence.c
> > @@ -412,7 +412,7 @@ static int test_wait_timeout(void *arg)
> >
> > err = 0;
> > err_free:
> > -
[ 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
[ 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: Sumit Semwal
Cc: "Christian König"
Cc: linux-me..
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: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freede
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()
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
[
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
[
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: Sumit
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
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: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedeskt
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
> +++
On Tue, 10 May 2022 08:38:38 +0900
Byungchul Park wrote:
> Yes, I was talking about A and L'.
>
> > detect that regardless of L. A nested lock associates the the nesting with
>
> When I checked Lockdep code, L' with depth n + 1 and L' with depth n
> have different classes in Lockdep.
If
On Mon, 9 May 2022 09:16:37 +0900
Byungchul Park wrote:
> CASE 2.
>
>lock L with depth n
>lock A
>lock_nested L' with depth n + 1
>...
>unlock L'
>unlock A
>unlock L
>
> This case is allowed by Lockdep.
> This case is *NOT* allowed by DEPT cuz it's a *DEADLOCK*.
>
On Thu, 17 Feb 2022 19:57:38 +0900
Byungchul Park wrote:
> diff --git a/include/linux/dept.h b/include/linux/dept.h
> new file mode 100644
> index 000..2ac4bca
> --- /dev/null
> +++ b/include/linux/dept.h
> @@ -0,0 +1,480 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + *
On Thu, 17 Feb 2022 10:51:09 -0500
"Theodore Ts'o" wrote:
> I know that you're trying to help us, but this tool needs to be far
> better than Lockdep before we should think about merging it. Even if
> it finds 5% more potential deadlocks, if it creates 95% more false
> positive reports --- and
On Thu, 17 Feb 2022 19:57:46 +0900
Byungchul Park wrote:
> +static int __init dept_proc_init(void)
> +{
> + proc_create_seq("dept_deps", S_IRUSR, NULL, _deps_ops);
> + proc_create_single("dept_stats", S_IRUSR, NULL, dept_stats_show);
> + return 0;
> +}
> +
>
On Thu, 17 Feb 2022 19:57:38 +0900
Byungchul Park wrote:
> diff --git a/kernel/dependency/Makefile b/kernel/dependency/Makefile
> new file mode 100644
> index 000..9f7778e
> --- /dev/null
> +++ b/kernel/dependency/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
>
On Wed, 16 Feb 2022 10:09:14 -0800
Linus Torvalds wrote:
> Byungchul, could you fix those two issues? Some of your reports may
> well be entirely valid, but the hard-to-read hex offsets and the
> knowledge that at least some of them are confused about how
> prepare_to_wait -> wait actually works
On Wed, 19 Jan 2022 21:25:08 +0200
Andy Shevchenko wrote:
> > I say keep it one line!
> >
> > Reviewed-by: Steven Rostedt (Google)
>
> I believe Sakari strongly follows the 80 rule, which means...
Checkpatch says "100" I think we need to simply update
On Wed, 19 Jan 2022 21:22:57 +0200
Andy Shevchenko wrote:
> On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no";
> > > > > > }
> > >
> > > return "yes\0no" + v * 4;
> > >
> > > :-)
> >
> > except
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
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
>
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
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
> |
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'
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
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
On Thu, 21 Oct 2021 13:56:38 +0200
Daniel Vetter wrote:
> Yay, that patch is just impressive. Lands a new gpu tracepoints, never
> even showed up on the gpu subsystem discussion list.
I'm guessing there was some confusion. When this was first introduced, I
stated it needs to go into the gpu
On Wed, 20 Oct 2021 20:10:24 -0700
Gurchetan Singh wrote:
> @@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
> drm_gem_remove_prime_handles(obj, file_priv);
> drm_vma_node_revoke(>vma_node, file_priv);
>
> + drm_gem_trace_gpu_mem_instance(dev,
On Wed, 20 Oct 2021 20:10:23 -0700
Gurchetan Singh wrote:
> - drm_gem_private_object_init(..) increases the total memory
> counter.
>
> * All GEM objects (whether allocated or imported) seem to begin
> there.
> * If there's a better place/method, please do let
> me know.
>
> -
;__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
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
writing beyond
> the target struct member.
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Signed-off-by: Kees Cook
> ---
> kernel/trace/trace.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trac
On Wed, 30 Jun 2021 04:28:39 -0700
Joe Perches wrote:
> On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> > The __assign_str macro has an unusual ending semicolon but the vast
> > majority of uses of the macro already have semicolon termination.
>
> ping?
>
I wasn't sure I was the one
On Sat, 12 Jun 2021 08:42:27 -0700
Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
>
> $ git grep -P '\b__assign_str\b' | wc -l
> 551
> $ git grep -P '\b__assign_str\b.*;' | wc -l
> 480
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
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:
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:
>
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
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"
[ 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
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
On Thu, 17 Dec 2020 11:03:20 +0100
Daniel Vetter wrote:
> I think we're tripping over the might_sleep() all the mutexes have,
> and that's not as good as yours, but good enough to catch a missing
> rcu_read_unlock(). That's kinda why I'm baffled, since like almost
> every 2nd function in the
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
>
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
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
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
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
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
___
dri-devel mailing list
1 - 100 of 217 matches
Mail list logo
