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 *crtc
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, TRACE
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(+)
>
> dif
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 *crtc_stat
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 they will
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 week of
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 wh
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
> >
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:
>
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 drivers/cxl/core/t
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 point
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 inst
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'
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
> style
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 '"
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 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 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 Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
> Trace something useful instead of the pid of a kernel thread here.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd
On Wed, 12 Aug 2020 16:36:36 +0200
Christian König wrote:
> Am 12.08.20 um 16:17 schrieb Steven Rostedt:
> > On Fri, Aug 07, 2020 at 03:36:58PM +0200, Christian König wrote:
> >> Trace something useful instead of the pid of a kernel thread here.
> >>
> >
On Thu, 19 Oct 2023 04:07:35 +0800
kernel test robot wrote:
> Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml:
> Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml:
> fs/tracefs/event_inode.c:782:11-21: ERROR: ei is NULL but dereferenced.
This was already reported and I'm currently test
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
> +++ b/include/trace/event
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 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 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 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:
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 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 be
On Fri, 14 Jul 2023 09:50:17 +0700
Bagas Sanjaya wrote:
> Hi,
>
> I notice a regression report on Bugzilla [1]. Quoting from it:
>
>
> See Bugzilla for the full thread and attached patches that fixes
> this regression.
>
> Later, when bisecting, the reporter got better kernel trace:
>
> > [
On Fri, 14 Jul 2023 14:34:04 +0900
wrote:
> >> > So I'm confused about why it's mentioned. Was it backported?
> >>
> >> Taketo Kabe, could you please help to clean this confusion up? Did you
> >> mean 5.19 in https://bugzilla.kernel.org/show_bug.cgi?id=217669#c5 ? And
> >> BTW: did you really
On Sat, 15 Jul 2023 11:39:11 +0900
wrote:
> Yes, this is puzzling. That's why I need other people's opinion on this.
> Does it matter the DUT is a slow machine (Pentium 120MHz)?
>
Hmm, I wonder because the workqueue is running __init functions, could it
possibly be that it didn't finish before
On Fri, 14 Jul 2023 14:34:04 +0900
wrote:
> Patch in
> https://bugzilla.kernel.org/show_bug.cgi?id=217669#c4
> fixed the problem in freedesktop.org kernel 5.18.0-rc2 .
> This may explain that in kernel.org tree, the said commit is in kernel-5.19.
You mean the patch that adds:
#if define
On Sun, 23 Jul 2023 20:55:06 +0900
wrote:
> So I tried to trap NULL and return:
>
> patch-drm_vblank_cancel_pending_works-printk-NULL-ret.patch
> diff -up ./drivers/gpu/drm/drm_vblank_work.c.pk2
> ./drivers/gpu/drm/drm_vblank_work.c
> --- ./drivers/gpu/drm/drm_vblank_work.c.pk2
On Sat, 22 Jul 2023 11:30:14 +0900
wrote:
> >> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> >> index 897cf02c20b1..801f4414da3e 100644
> >> --- a/arch/x86/include/asm/ftrace.h
> >> +++ b/arch/x86/include/asm/ftrace.h
> >> @@ -13,7 +13,7 @@
> >> #ifdef CONFIG_HAVE_
On Thu, 28 Mar 2019 19:10:07 +0100
Andrey Konovalov wrote:
> > > Signed-off-by: Andrey Konovalov
> > > ---
> > > ipc/shm.c | 2 ++
> > > mm/madvise.c | 2 ++
> > > mm/mempolicy.c | 5 +
> > > mm/migrate.c | 1 +
> > > mm/mincore.c | 2 ++
> > > mm/mlock.c | 5 +
> > > mm/
EXPORT_SYMBOL_GPL(__trace_bprintk);
>
> int __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap)
> - {
> +{
> if (unlikely(!fmt))
> return 0;
>
Acked-by: Steven Rostedt (VMware)
-- Steve
___
amd-gfx mailing lis
40 matches
Mail list logo
