[PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size
Steven Rostedt
rostedt at goodmis.org
Tue Feb 9 16:34:31 EST 2021
On Tue, 9 Feb 2021 14:55:31 -0500
Steven Rostedt <rostedt at goodmis.org> wrote:
> > [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
> > https://lore.kernel.org/lkml/f16b14066317f6a926b6636df6974966@codeaurora.org/
>
> Note, that is only used when filtering happens, which doesn't appear to be
> the case here.
I was basing this off of the original commands, but the stack dump says
otherwise. But it should still work.
>
> >
> > It seems like we should still try to get that fixed somehow, even if
> > the below change is fine on its own (it probably doesn't make sense to
> > such a large amount of data via tracepoints). It would be unfortunate
> > for next poor soul to hit the same issues, just because they wanted to
> > dump a few KB.
>
> Yeah, it was a design decision to cap the max size of events to just under
> PAGE_SIZE. The ring buffer is broken up into pages (for zero copy
> transfers to file systems and the network). Thus, no event is allowed to be
> bigger than a page (and actually a bit smaller)
>
> That said, it shouldn't have crashed, it should have just failed to record.
>
> I'll test it out and see why it crashed.
Looking at the original report, I see:
CPU: 1 PID: 141 Comm: kworker/u16:1 Not tainted 4.19.139 #162
Does this still crash on the latest kernel?
-- Steve
More information about the ath10k
mailing list