Re: [PATCH] ppc/fadump: collect dump if the collected size is lesser than reserved
Sourabh Jain <[email protected]> Wed, 29 Jul 2026 09:14:49 +0530
| Newsgroups | org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 22/07/26 14:41, Shivang Upadhyay wrote: > On Sun, 2026-07-19 at 12:39 +0530, Sourabh Jain wrote: >> Could you please reword the commit title to make it a bit clearer? >> >> >> On 14/07/26 23:00, Shivang Upadhyay wrote: >>> When a machine is subjected to CPUs add/remove, using dlpar >>> operations, the number of collected CPU_NOTES can change. >>> As per PAPR, collected dump size should not be more than >>> allocated size. Reflecting the same in source. >> Can you add more details about the problem you are trying to solve >> with this patch and how. >> >> Adding the error message and scenario would be really helpful in >> understanding the problem. >> > Hi Sourabh, > > When a qemu ppc machine is booted with fadump=on and `- > smp=x,maxcpus=y`, on the panic kernel, /proc/vmcore is not generated > because dump_bytes and source_len does'nt match for CPU_STATE_DATA > region in fadump, then we just give up on parsing rest of the data. > > >> Can you add Closes tag if it is reported upstream and if possible >> fixes >> tag too. >> >>> Signed-off-by: Shivang Upadhyay <[email protected]> >>> --- >>> arch/powerpc/platforms/pseries/rtas-fadump.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.c >>> b/arch/powerpc/platforms/pseries/rtas-fadump.c >>> index 3bb4ac2ab6cc..19a5adaf326b 100644 >>> --- a/arch/powerpc/platforms/pseries/rtas-fadump.c >>> +++ b/arch/powerpc/platforms/pseries/rtas-fadump.c >>> @@ -469,7 +469,8 @@ static int __init rtas_fadump_process(struct >>> fw_dump *fadump_conf) >>> pr_err("Dump taken by platform is >>> not valid (%d)\n", i); >>> rc = -EINVAL; >>> } >>> - if (fdm_active->rgn[i].bytes_dumped != >>> fdm_active->rgn[i].source_len) { >>> + if (be64_to_cpu(fdm_active- >>>> rgn[i].bytes_dumped) >>> + > be64_to_cpu(fdm_active- >>>> rgn[i].source_len)) { >> Can you please share your observations about `bytes_dump` for both >> QEMU >> and a >> real system (LPAR) where the number of online CPUs is not equal to >> the >> maximum > I have the following observation. > > I booted LPAR with 8 cpus. After crashing it I saw that fadump > CPU_STATE_DATA has notes for total 16 cpus, and only top 8 notes have > valid entries.when trying with 16, I see all NOTES have entried > filled. Yes even I noticed the same on a LPAR with (Min=1 Desired=1 Max=2 with SMT=8 CPUs) maxcpus as 16 and online CPUs as 8. [ 0.036128] rtas fadump: --------CPU State Data------------ [ 0.036129] rtas fadump: Magic Number: 5245475341564500 [ 0.036131] rtas fadump: NumCpuOffset: 1c [ 0.036132] rtas fadump: NumCpus : 16 [ 0.036135] fadump: Allocated buffer for cpu notes of size 65536 at 0xc000000006a30000 [ 0.036138] rtas fadump: Reading register data for cpu 0... [ 0.036173] rtas fadump: Reading register data for cpu 1... [ 0.036178] rtas fadump: Reading register data for cpu 2... [ 0.036209] rtas fadump: Reading register data for cpu 3... [ 0.036240] rtas fadump: Reading register data for cpu 4... [ 0.036272] rtas fadump: Reading register data for cpu 5... [ 0.036304] rtas fadump: Reading register data for cpu 6... [ 0.036335] rtas fadump: Reading register data for cpu 7... [ 0.036390] rtas fadump: Updating elfcore header (c000000006a20000) with cpu notes The NumCpus is populated to be 16 CPUs by the firmware (RTAS/PHYP) even though only 8 CPUs were online. Kernel avoid processing reg entries of CPUs which were offline using below condition. code snippet from rtas_fadump_build_cpu_notes()/rtas-faudmp.c if (fdh && !cpumask_test_cpu(cpu, &fdh->cpu_mask)) { RTAS_FADUMP_SKIP_TO_NEXT_CPU(reg_entry); continue; } But when I removed the avoid condition kernel failed to process the reg entries and below logs were printed. [ 0.037877] rtas fadump: --------CPU State Data------------ [ 0.037879] rtas fadump: Magic Number: 5245475341564500 [ 0.037881] rtas fadump: NumCpuOffset: 1c [ 0.037883] rtas fadump: NumCpus : 16 [ 0.037889] fadump: Allocated buffer for cpu notes of size 65536 at 0xc000000007a50000 [ 0.037891] rtas fadump: Reading register data for cpu 0... [ 0.037937] rtas fadump: Reading register data for cpu 1... [ 0.037974] rtas fadump: Reading register data for cpu 2... [ 0.038009] rtas fadump: Reading register data for cpu 3... [ 0.038044] rtas fadump: Reading register data for cpu 4... [ 0.038079] rtas fadump: Reading register data for cpu 5... [ 0.038082] rtas fadump: Reading register data for cpu 6... [ 0.038117] rtas fadump: Reading register data for cpu 7... [ 0.038155] rtas fadump: CPU 8 was offline [ 0.038157] rtas fadump: Reading register data for cpu 8... [ 0.038195] rtas fadump: CPU 10 was offline [ 0.038197] rtas fadump: Reading register data for cpu 10... [ 0.038235] rtas fadump: CPU 12 was offline [ 0.038236] rtas fadump: Reading register data for cpu 12... [ 0.038273] rtas fadump: CPU 14 was offline [ 0.038275] rtas fadump: Reading register data for cpu 14... [ 0.038311] rtas fadump: Unable to read CPU state data [ 0.038319] fadump: Invalidating firmware-assisted dump registration [ 0.038370] rtas fadump: Firmware busy during fadump invalidate, waiting 1ms (total 0ms) [ 0.039403] fadump: reserved_memory_range[0] [0x00000040000000-0x000000800305c7], 0x400305c8 bytes [ 0.039408] fadump: freeing reserved memory (0x80030000 - 0xa00000000) For some reason, only CPUs with even-numbered IDs were present from offline CPUs list. This suggests that although NumCpus was 16, only 8 CPUs had valid reg entries. I think we should discuss this case with the firmware team before finalizing the solution. On the other hand when I increased the CPUs count on the same system (Min=2 Desired=4 and max=8 with SMT 8) the system was booted with 32 possible CPUs instead of 64 CPUs. And NumCpus was 32 in fadump kernel. > > I previously proposed this fake entries fix in qemu [1]. But that is > not compliant with PAPR, which states that cpu notes should be > collected for current_cpus only. Yes, that solution does not appear to be PAPR-compliant. However, based on our experiments, it is unclear why the firmware reports NumCpus as 16 when only 8 CPUs are actually online. > As per current states of things, reservation is always done for > maxcpus, (LPAR and QEMU both), NOTES collections is done for current > cpus on QEMU, and maxcpus on LPARs. > > My proposal here is that we make the check for bytes_dumped and > source_len, less restrictive to let QEMU also generate /proc/vmcore, > when current_cpus != maxcpus. By the way, the changes proposed in this patch also apply to other regions, such as HPTE and REAL_MODE. That is not the intended behavior, right? - Sourabh Jain > > > Regards > ~Shivang. > > [1] > https://lore.kernel.org/qemu-devel/[email protected]/ >