On Wed, 19 Nov 2025 17:44:01 +0200 Eugen Hristev <[email protected]> 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
