On 2022/07/22 21:04, Agrain Patrick wrote: > Hello, > > Back to this topic. > > I upgraded our system with the kexec-tools from Centos 8 Stream, based on kexec 2.0.24 and makedumpfile 1.7.1. > We are still facing errors when using 'makedumpfile -c'. > > Removing the '-c' gives better ratio success/failure, but sometimes the crash file cannot be read by the crash tool. > > Referring to Hagio's remark below concerning the sync, I added a sync operation before the call of makedumpfile (and just after the mount ext4 of the required partitions) and add a second call to sync after the return of makedumpfile. > In that configuration, the crash file can be read by the crash tool (up to now in all cases). Good, seems the second sync works. I would suggest unmounting the filesystem cleanly, which contains syncing to disk, before reboot, if you don't do that. Thanks, Kazu > > Thanks for your help. > Best regards, > Patrick Agrain > > -----Message d'origine----- > De : Crash-utility <crash-utility-bounces@xxxxxxxxxx> De la part de Agrain Patrick > Envoyé : mercredi 6 avril 2022 17:48 > À : Discussion list for crash utility usage, maintenance and development <crash-utility@xxxxxxxxxx>; kexec@xxxxxxxxxxxxxxxxxxx > Objet : Re: [Crash-utility] EXT: RE: crash: read error on type: "memory section root table" > > > > -----Message d'origine----- > De : HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> Envoyé : mercredi 6 avril 2022 09:48 À : Agrain Patrick <patrick.agrain@xxxxxxxxxxxxxxxxx> > Cc : Discussion list for crash utility usage, maintenance and development <crash-utility@xxxxxxxxxx>; kexec@xxxxxxxxxxxxxxxxxxx Objet : RE: EXT: RE: crash: read error on type: "memory section root table" > > -----Original Message----- >> Hello, >> >> Suggested trace above gives following information after a crash -d 8 command: >> <...> >> kernel NR_CPUS: 2 >> <readmem: ffffffffa4925820, KVADDR, "high_memory", 8, (FOE), >> 56017b542648> >> <read_diskdump: addr: ffffffffa4925820 paddr: 12925820 cnt: 8> >> read_diskdump: paddr/pfn: 12925820/12925 -> cache physical page: >> 12925000 >> GETBUF(328 -> 0) >> FREEBUF(0) >> GETBUF(328 -> 0) >> FREEBUF(0) >> PAGESIZE=4096 >> mem_section_size = 16384 >> NR_SECTION_ROOTS = 2048 >> NR_MEM_SECTIONS = 524288 >> SECTIONS_PER_ROOT = 256 >> SECTION_ROOT_MASK = 0xff >> PAGES_PER_SECTION = 32768 >> <readmem: ffffffffa4926db0, KVADDR, "mem_section", 8, (FOE), >> 7ffd1b6bb000> >> <read_diskdump: addr: ffffffffa4926db0 paddr: 12926db0 cnt: 8> >> read_diskdump: paddr/pfn: 12926db0/12926 -> cache physical page: >> 12926000 >> <readmem: ffff904c7f7fc000, KVADDR, "memory section root table", >> 16384, (FOE), 56017da26fd0> >> <read_diskdump: addr: ffff904c7f7fc000 paddr: 3f7fc000 cnt: 4096> >> read_diskdump: paddr/pfn: 3f7fc000/3f7fc -> cache physical page: >> 3f7fc000 >> crash: PAG3 - errno=2 r=0 pd.size=49 >> read_diskdump: READ_ERROR: cannot cache page: 3f7fc000 >> crash: read error: kernel virtual address: ffff904c7f7fc000 type: "memory section root table" > > hmm, r=0 means end of file, can you check again whether pd.offset exceeds the dumpfile size? If so, somehow the dumpfile is shorter than expected. > > Indeed, the offset points outside the dumpfile: > Get: > crash: PAG3 - errno=2 r=0 pd.size=52 pd.offset=168956485 with a dumpfile > 164820 -rw-r--r--. 1 root root 168775680 6 avril 17:23 crashdump--20220406-1713 > > And another one: > Get: > crash: PAG3 - errno=2 r=0 pd.size=49 pd.offset=215640649 with a dumpfile > 209984 -rw-r--r--. 1 root root 215023616 1 avril 10:58 crashdump-585.000-20220401-1054 > > I think a RHEL-based kexec-tools does "sync" after makedumpfile, but can you check? > > Actually, we are executing the makedumpfile in a script designated as init file for the second kernel. Therefore, we do not perform the sync as per core_collector. > > Thanks, > Kazu > > Best regards, > Patrick > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/crash-utility > Contribution Guidelines: https://github.com/crash-utility/crash/wiki > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/crash-utility > Contribution Guidelines: https://github.com/crash-utility/crash/wiki _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
