On Wed, 19 Nov 2025 20:24:23 +0200 Eugen Hristev <[email protected]> wrote:
> The problem is that all the meta-data is not allocated inside the > preallocated buffer. The meta-data is kmalloced all around the code. I > mean the structs that hold the information on what's in the buffer. You > know what I mean. > And all these kmalloced things, turn out to be in order of hundreds just > on a kernel boot, which I tested. This is not feasible for the > meminspect table, as it would get overcrowded very easily. > I thought of perhaps trying to kmalloc all of them in a dedicated cache, > but I haven't progressed on that. Another idea would be to try to > recreate the meta, but I have not found a way to do it yet.> > > 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. > > > I used 'crash' tool with trace plugin and I am able to see all the trace > contents, but, with the limitation above. (To achieve this, I dumped a > huge area to include it, so , not feasible for my goal ) Can't you at boot up just run: trace-cmd restore -c -o trace-head.dat ? That records all the meta data of the running machine, and places it into a trace-head.dat file. You can save that off anywhere. Then after a crash, if you split the buffers up into individual cpu raw data files, you can then run: trace-cmd restore -o trace.dat -i trace-head.dat trace-cpu0.raw trace-cpu1.raw ... And it will create a trace.dat file for you that you can read with: trace-cmd report trace.dat -- Steve
