On Wed, Jan 3, 2024 at 11:27 PM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote: > > > One more thing, kernel part of minidump, we are calling it APSS Minidump > has limitation of no of entries so it will be difficult to dump > non-continuous regions after a certain number of registration ~200. However, > we do have a solution in downstream kernel for it like to create a big > CMA buffer and register this buffer with Minidump so that whatever gets > dumped in that buffer gets captured during crash and fill up this buffer > and create elf during panic. I think, similar thing you are also doing > with your OS-minidump. > > I have just glanced into your implementation of OS-minidump, it > more of relying on basic concept of RAM content preserved > across boot and later reading it through procfs but this basic > stuff is common to pstore(ram) as well and pstore has file system > support why don't you make your driver as one of pstore record and that > way Qualcomm minidump also gets benefited where entire OS-minidump > record gets registered with Qualcomm minidump and we get this on panic > and you get this via pstorefs. > Thanks Mukesh！It is a good suggestion to move OS-minidump forward! By the way, I have some questions here for which I need your assistance. Firstly,I can reimplement OS-minidump as one of the pstore records to dump data. The resulting dump file would contain thousands of non-contiguous memory regions, each with only the virtual address and size recorded. As far as I know, Qualcomm's minidump can handle several memory regions, each with a physical address and size. This seems to be a difference, and I'm curious as to how you deal with data dumped by OS-minidump. I would really appreciate it if you could provide more details on your approach. Secondly, what tools do you use to analyze the dump data, and does it support crash tool? Lastly, is Qualcomm minidump compatible with non-Qualcomm SoCs, and if so, how can one use it? Best Regards Ruipeng Qi
