[PATCH] kdump : Support kernels having 64k page size.

[PATCH] kdump : Support kernels having 64k page size.

[Sachin P. Sant]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

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



[-- Attachment #2: ppc64-kexec-tools-64k-page-support --]
[-- Type: text/plain, Size: 663 bytes --]

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

Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---

diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
--- a/include/asm-powerpc/kdump.h	2006-08-31 03:01:13.000000000 +0530
+++ b/include/asm-powerpc/kdump.h	2006-08-31 05:49:13.000000000 +0530
@@ -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
 

Re: [PATCH] kdump : Support kernels having 64k page size.

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On Wed, 2006-09-06 at 05:56 +0530, Sachin P. Sant wrote:
> The following  kernel patch [ along with a patch to kexec tools posted 
> seperately ]
> is required to generate proper core files using kdump on ppc64.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [PATCH] kdump : Support kernels having 64k page size.

[Haren Myneni]

Michael Ellerman wrote:

>On Wed, 2006-09-06 at 05:56 +0530, Sachin P. Sant wrote:
>  
>
>>The following  kernel patch [ along with a patch to kexec tools posted 
>>seperately ]
>>is required to generate proper core files using kdump on ppc64.
>>    
>>
>
>Hi Sachin,
>
>Can you provide some more explanation? It's not clear to me why this is
>necessary.
>
>thanks
>
>  
>
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





>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

Re: [PATCH] kdump : Support kernels having 64k page size.

[Benjamin Herrenschmidt]

> 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.

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 ?

> 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);

Re: [PATCH] kdump : Support kernels having 64k page size.

[Sachin P. Sant]

> 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

Re: [PATCH] kdump : Support kernels having 64k page size.

[Benjamin Herrenschmidt]

On Fri, 2006-09-08 at 06:30 +0530, Sachin P. Sant wrote:
> > 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 ?

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

Ben.

[PATCH] kdump : Support kernels having 64k page size.

[Sachin P. Sant]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

Benjamin Herrenschmidt wrote:
> On Fri, 2006-09-08 at 06:30 +0530, Sachin P. Sant wrote:
>   
>>> 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 ?
>>     
>
> 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.

Signed-off-by: Sachin Sant <sachinp@in.ibm.com>

Thanks
-Sachin

[-- Attachment #2: 64k-backup-size-for-kdump --]
[-- Type: text/plain, Size: 1073 bytes --]

* 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. 

Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---

diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
--- a/include/asm-powerpc/kdump.h	2006-09-01 00:40:10.000000000 +0530
+++ b/include/asm-powerpc/kdump.h	2006-09-08 07:12:18.000000000 +0530
@@ -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