[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