On Sat, Dec 23, 2023 at 10:23 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > Qcom minidump can dump some logs like dmsg, some status like IRQ or > > Run queue. This can help to learn some information when the issue occurs, > > which will help to find out the root cause. But what it dumps are limited, it > > doesn't dump w and lock if they are not local data. > > So add missing features to it. I don't think you got my comment and keep > arguing on the same thing repeated for upstream submissions many times. > We do not want multiple vendor solutions. Every vendor wants his work > and does not care about integrating or reusing other pieces. > > > > > For osdump, it dumps objects stored in slab, datas in bss, data segments, > > some data alloced with memblock, data stored in local stack, and so on. > > In a word, it dumps almost all of the key data in the kernel. Besides, you > > can use the crash tool to analyze the dump file. > > I don't see a problem why minidump cannot do it. Qcom minidump allows one kernel client to register its region to dump, and then driver will create and maintain one elf head for it. But osdump will dump thousands of non-continuous regions. If you register one by one, and add an elf head for each, it will cause heavy overhead. So it store data in binary, and reassemble a standard elf format file offline for debug. Sir, I am not really familiar with Qcom minidump, and some options may be wrong. But do you think it is ok to integrate osdump to Qcom? Looking forward to your suggestions! Best Regards Ruipeng _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
