Re: [PATCH 00/26] Introduce meminspect

Steven Rostedt
2025-11-19T18:15:14Z

On Wed, 19 Nov 2025 17:44:01 +0200
Eugen Hristev <eugen.hristev@linaro.org> wrote:

> Once you have all the files simply use `cat` to put them all together,
> in the order of the indexes.
> For my kernel config and setup, here is my cat command : (you can use a script
> or something, I haven't done that so far):

Interesting. Hmm, it seems this could be used with the persistent ring
buffer code as well. But if the firmware does not keep the memory around on
reboot (where the buffer would be reloaded), you could mark the persistent
ring buffer's memory to be inspected.

The persistent ring buffer creates a single allocation to hold all per-cpu
memory in a single region. That is, because on a crash and reboot, it
expects that memory to be at the same location and does a verification
check to see if it contains a valid buffer. If it does, it will recreate it
for view in the instance directory of choice.

Now if this same range is marked for inspection, you could then download
the entire contents of the persistent ring buffer after a crash. It would
be trivial to update trace-cmd's restore functionality to rebuild a
trace.dat file from it. It would require saving the event formats of the
running kernel before the crash, but that's not hard to do.

That is, by using the persistent ring buffer code with the meminspect, if
the firmware doesn't save the memory across reboots but allows you to dump
it to disk, you can enable tracing within the persistent ring buffer, on
crash, extract the buffer, and then use trace-cmd to rebuild a trace.dat
file that you can now inspect, and see the trace that lead up to the crash.

Now I don't have any hardware that uses this feature (not that I know of),
but if others find this useful, I would most definitely help them implement
it.

-- Steve