kdump : Support kernels having 64k page size.

The following kernel patch [ along with a patch to kexec tools posted seperately ] is required to generate proper core files using kdump on ppc64.

Thanks
-Sachin

* Generate proper core files using kdump on ppc64 with 64k page support.

---

diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
@@ -7,7 +7,7 @@
 /* How many bytes to reserve at zero for kdump. The reserve limit should
  * be greater or equal to the trampoline's end address.
  * Reserve to the end of the FWNMI area, see head_64.S */
-#define KDUMP_RESERVE_LIMIT	0x8000
+#define KDUMP_RESERVE_LIMIT	max(0x8000, PAGE_SIZE)
 
 #ifdef CONFIG_CRASH_DUMP
 

Hi Sachin,

Can you provide some more explanation? It's not clear to me why this is necessary.

thanks

Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

At present we are doing the backup of 32K. Thus created one ELF PT_LOAD segment for this region.
But, in the case of 64K page size, second segments starts at 32K and the first one is not page aligned. __ioremap() (crash_dump.c) getting failed if pfn = 0 which is the case for the second PT_LOAD segment. We did not hit this issue for 4K page size because the the first page (32K backup) is copied to second kernel memory and thus referencing with the second kernel pfn.

Here the fix is, backup regions size is max(PAGE_SIZE, 32K) so that at least one page will be part of backup ELF segment. Drawback here is, we will end up 32K more for backup for 64K page size.

It can also be fixed in copy_oldmem_page() (crash_dump.c), but first PT_LOAD segment is not page aligned:

if (pfn > 0)
vaddr = __ioremap(pfn << PAGE_SHIFT, PAGE_SIZE, 0);
else
vaddr = __va(pfn << PAGE_SHIFT);

Thanks
Haren

You should always do 64k regardless of the page size. I think we have some ABI requirements here for ELF sections to be 64k aligned anyway no ?

Ben are you aware of any doc where i can find more information. I checked the 64Bit PowerPC ELF ABI doc but couldn't find any specific information about this.

Also other question is If we create a 64k segment irrespective of page size [ as compared to 32k currently ] we would be writing extra 32k even for page size of 4K. Which means we have 32k less memory for the kdump kernel. Wouldn't that be an issue ?

Thanks
-Sachin

32k sounds like a drop of water in the kdump pool ...

Ben.

The following kernel patch [ along with a patch to kexec tools posted seperately ]is required to generate proper core files using kdump on ppc64.

* Create a backup region of 64K size irrespective of the PAGE SIZE. At present 32K was used as backup size. In the case of 64K page size, second PT_LOAD segments starts at 32K and the first one is not page aligned. __ioremap() (crash_dump.c) fails if pfn = 0 which is the case for the
second
PT_LOAD segment. This is not an issue for 4K page size because the the
first
page (32K backup) is copied to second kernel memory and thus referencing with the second kernel pfn.

Thanks
-Sachin

* Create a backup region of 64K size irrespective of the PAGE SIZE. At present 32K was used as backup size. In the case of 64K page size, second PT_LOAD segments starts at 32K and the first one is not page aligned. __ioremap() (crash_dump.c) fails if pfn = 0 which is the case for the second PT_LOAD segment. This is not an issue for 4K page size because the the first page (32K backup) is copied to second kernel memory and thus referencing with the second kernel pfn.

---

diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
@@ -7,7 +7,7 @@
 /* How many bytes to reserve at zero for kdump. The reserve limit should
  * be greater or equal to the trampoline's end address.
  * Reserve to the end of the FWNMI area, see head_64.S */
-#define KDUMP_RESERVE_LIMIT	0x8000
+#define KDUMP_RESERVE_LIMIT	0x10000 /* 64K */
 
 #ifdef CONFIG_CRASH_DUMP