Re: kdump broken on Altix 350

2008-10-01 Thread Simon Horman 
On Mon, Sep 29, 2008 at 04:42:52PM -0700, Luck, Tony wrote:
 Does this make kexec/kdump happier?  Bare minimum testing so far
 (builds and boots on tiger ... didn't try kexec yet).

Hi Tony,

your analysis (in your previous email) was more or less the same
conclusion that I had come too, though I was puzzling over
why you had put the reserved area for cpu0 where you had - I assumed
I was misunderstanding things.

This patch looks good to me.

Jay,

With this patch I assume that we still need an order of operations fix for
kexec-tools but no section merging changes. Is that correct?

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump broken on Altix 350

2008-09-29 Thread Luck, Tony 
Maybe I'm starting to see what happened ... and it could well
be my fault.

I wanted to allocate the per-cpu memory for cpu0 statically
in the vmlinux ... so it would be available in head.S to set
up everything before we move to any C code that might try to
access per cpu variables.  To make life easy for myself I just
made this allocation in vmlinus.lds.S immediately before the
initialized block where all the percpu variables live (which
means no extra labels ... and I could initialize this data
with a simple copy of PERCPU_PAGESIZE bytes from (the poorly
named) __phys_per_cpu_start to the unamed block before it
that will be the cpu0 copy.

But my extra allocation is in the percpu block in vmlinux.lds.S,
so it ends up in that PT_LOAD section.  Which ultimately confuses
the kexec code.

Probably the cpu0 percpu space should be placed in the data section.

-Tony

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump broken on Altix 350

2008-09-29 Thread Luck, Tony 
Does this make kexec/kdump happier?  Bare minimum testing so far
(builds and boots on tiger ... didn't try kexec yet).



[IA64] Put the space for cpu0 per-cpu area into .data section

Initial fix for making sure that we can access percpu variables
in all C code commit: 10617bbe84628eb18ab5f723d3ba35005adde143
inadvertantly allocated the memory in the percpu section of
the vmlinux ELF executable.  This confused kexec.

Signed-off-by: Tony Luck [EMAIL PROTECTED]

diff --git a/arch/ia64/include/asm/sections.h b/arch/ia64/include/asm/sections.h
index f667998..1a873b3 100644
--- a/arch/ia64/include/asm/sections.h
+++ b/arch/ia64/include/asm/sections.h
@@ -11,6 +11,9 @@
 #include asm-generic/sections.h
 
 extern char __per_cpu_start[], __per_cpu_end[], __phys_per_cpu_start[];
+#ifdef CONFIG_SMP
+extern char __cpu0_per_cpu[];
+#endif
 extern char __start___vtop_patchlist[], __end___vtop_patchlist[];
 extern char __start___rse_patchlist[], __end___rse_patchlist[];
 extern char __start___mckinley_e9_bundles[], __end___mckinley_e9_bundles[];
diff --git a/arch/ia64/kernel/head.S b/arch/ia64/kernel/head.S
index 8bdea8e..66e491d 100644
--- a/arch/ia64/kernel/head.S
+++ b/arch/ia64/kernel/head.S
@@ -367,16 +367,17 @@ start_ap:
;;
 #else
 (isAP) br.few 2f
-   mov r20=r19
-   sub r19=r19,r18
+   movl r20=__cpu0_per_cpu
;;
shr.u r18=r18,3
 1:
-   ld8 r21=[r20],8;;
-   st8[r19]=r21,8
+   ld8 r21=[r19],8;;
+   st8[r20]=r21,8
adds r18=-1,r18;;
cmp4.lt p7,p6=0,r18
 (p7)   br.cond.dptk.few 1b
+   mov r19=r20
+   ;;
 2:
 #endif
tpa r19=r19
diff --git a/arch/ia64/kernel/vmlinux.lds.S b/arch/ia64/kernel/vmlinux.lds.S
index de71da8..10a7d47 100644
--- a/arch/ia64/kernel/vmlinux.lds.S
+++ b/arch/ia64/kernel/vmlinux.lds.S
@@ -215,9 +215,6 @@ SECTIONS
   /* Per-cpu data: */
   percpu : { } :percpu
   . = ALIGN(PERCPU_PAGE_SIZE);
-#ifdef CONFIG_SMP
-  . = . + PERCPU_PAGE_SIZE;/* cpu0 per-cpu space */
-#endif
   __phys_per_cpu_start = .;
   .data.percpu PERCPU_ADDR : AT(__phys_per_cpu_start - LOAD_OFFSET)
{
@@ -233,6 +230,11 @@ SECTIONS
   data : { } :data
   .data : AT(ADDR(.data) - LOAD_OFFSET)
{
+#ifdef CONFIG_SMP
+  . = ALIGN(PERCPU_PAGE_SIZE);
+   __cpu0_per_cpu = .;
+  . = . + PERCPU_PAGE_SIZE;/* cpu0 per-cpu space */
+#endif
DATA_DATA
*(.data1)
*(.gnu.linkonce.d*)
diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
index e566ff4..0ee085e 100644
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -163,7 +163,7 @@ per_cpu_init (void)
 * get_zeroed_page().
 */
if (first_time) {
-   void *cpu0_data = __phys_per_cpu_start - PERCPU_PAGE_SIZE;
+   void *cpu0_data = __cpu0_per_cpu;
 
first_time=0;
 
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index 78026aa..d8c5fcd 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -144,7 +144,7 @@ static void *per_cpu_node_setup(void *cpu_data, int node)
 
for_each_possible_early_cpu(cpu) {
if (cpu == 0) {
-   void *cpu0_data = __phys_per_cpu_start - 
PERCPU_PAGE_SIZE;
+   void *cpu0_data = __cpu0_per_cpu;
__per_cpu_offset[cpu] = (char*)cpu0_data -
__per_cpu_start;
} else if (node == node_cpuid[cpu].nid) {

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump broken on Altix 350

2008-09-29 Thread Jay Lan 
Luck, Tony wrote:
 Does this make kexec/kdump happier?  Bare minimum testing so far
 (builds and boots on tiger ... didn't try kexec yet).

Hi Tony,

Yep, the 2.6.27-rc7 kdump kernel built with this patch worked fine!

Actually you probably can predict the results by doing 'readelf -l
vmlinux'. If the PT_LOAD headers do not have a gap betweens headers,
it is good. In other words, if the (PhysAddr+MemSiz) rounded up to
Align value of one header is the same as the PhysAddr of the next
header, kexec should produce a good boot memmap for the kdump kernel.


Thanks for the patch!

jay

 
 
 
 [IA64] Put the space for cpu0 per-cpu area into .data section
 
 Initial fix for making sure that we can access percpu variables
 in all C code commit: 10617bbe84628eb18ab5f723d3ba35005adde143
 inadvertantly allocated the memory in the percpu section of
 the vmlinux ELF executable.  This confused kexec.
 
 Signed-off-by: Tony Luck [EMAIL PROTECTED]
 
 diff --git a/arch/ia64/include/asm/sections.h 
 b/arch/ia64/include/asm/sections.h
 index f667998..1a873b3 100644
 --- a/arch/ia64/include/asm/sections.h
 +++ b/arch/ia64/include/asm/sections.h
 @@ -11,6 +11,9 @@
  #include asm-generic/sections.h
  
  extern char __per_cpu_start[], __per_cpu_end[], __phys_per_cpu_start[];
 +#ifdef   CONFIG_SMP
 +extern char __cpu0_per_cpu[];
 +#endif
  extern char __start___vtop_patchlist[], __end___vtop_patchlist[];
  extern char __start___rse_patchlist[], __end___rse_patchlist[];
  extern char __start___mckinley_e9_bundles[], __end___mckinley_e9_bundles[];
 diff --git a/arch/ia64/kernel/head.S b/arch/ia64/kernel/head.S
 index 8bdea8e..66e491d 100644
 --- a/arch/ia64/kernel/head.S
 +++ b/arch/ia64/kernel/head.S
 @@ -367,16 +367,17 @@ start_ap:
   ;;
  #else
  (isAP)   br.few 2f
 - mov r20=r19
 - sub r19=r19,r18
 + movl r20=__cpu0_per_cpu
   ;;
   shr.u r18=r18,3
  1:
 - ld8 r21=[r20],8;;
 - st8[r19]=r21,8
 + ld8 r21=[r19],8;;
 + st8[r20]=r21,8
   adds r18=-1,r18;;
   cmp4.lt p7,p6=0,r18
  (p7) br.cond.dptk.few 1b
 + mov r19=r20
 + ;;
  2:
  #endif
   tpa r19=r19
 diff --git a/arch/ia64/kernel/vmlinux.lds.S b/arch/ia64/kernel/vmlinux.lds.S
 index de71da8..10a7d47 100644
 --- a/arch/ia64/kernel/vmlinux.lds.S
 +++ b/arch/ia64/kernel/vmlinux.lds.S
 @@ -215,9 +215,6 @@ SECTIONS
/* Per-cpu data: */
percpu : { } :percpu
. = ALIGN(PERCPU_PAGE_SIZE);
 -#ifdef   CONFIG_SMP
 -  . = . + PERCPU_PAGE_SIZE;  /* cpu0 per-cpu space */
 -#endif
__phys_per_cpu_start = .;
.data.percpu PERCPU_ADDR : AT(__phys_per_cpu_start - LOAD_OFFSET)
   {
 @@ -233,6 +230,11 @@ SECTIONS
data : { } :data
.data : AT(ADDR(.data) - LOAD_OFFSET)
   {
 +#ifdef   CONFIG_SMP
 +  . = ALIGN(PERCPU_PAGE_SIZE);
 + __cpu0_per_cpu = .;
 +  . = . + PERCPU_PAGE_SIZE;  /* cpu0 per-cpu space */
 +#endif
   DATA_DATA
   *(.data1)
   *(.gnu.linkonce.d*)
 diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
 index e566ff4..0ee085e 100644
 --- a/arch/ia64/mm/contig.c
 +++ b/arch/ia64/mm/contig.c
 @@ -163,7 +163,7 @@ per_cpu_init (void)
* get_zeroed_page().
*/
   if (first_time) {
 - void *cpu0_data = __phys_per_cpu_start - PERCPU_PAGE_SIZE;
 + void *cpu0_data = __cpu0_per_cpu;
  
   first_time=0;
  
 diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
 index 78026aa..d8c5fcd 100644
 --- a/arch/ia64/mm/discontig.c
 +++ b/arch/ia64/mm/discontig.c
 @@ -144,7 +144,7 @@ static void *per_cpu_node_setup(void *cpu_data, int node)
  
   for_each_possible_early_cpu(cpu) {
   if (cpu == 0) {
 - void *cpu0_data = __phys_per_cpu_start - 
 PERCPU_PAGE_SIZE;
 + void *cpu0_data = __cpu0_per_cpu;
   __per_cpu_offset[cpu] = (char*)cpu0_data -
   __per_cpu_start;
   } else if (node == node_cpuid[cpu].nid) {
 --
 To unsubscribe from this list: send the line unsubscribe linux-ia64 in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump broken on Altix 350

2008-09-26 Thread Jay Lan 
Jay Lan wrote:
 Bernhard Walle wrote:
 * Luck, Tony [EMAIL PROTECTED] [2008-08-29]: 

 your commit

 commit 10617bbe84628eb18ab5f723d3ba35005adde143
 Author: Tony Luck [EMAIL PROTECTED]
 Date:   Tue Aug 12 10:34:20 2008 -0700

 [IA64] Ensure cpu0 can access per-cpu variables in early boot
 code

 broke kdump on our Altix 350. I get following early crash in kdump
 kernel
 Sorry about that.  I'll try to reproduce it here.
 I had some discussion about that with Jay Lan that he could not
 reproduce that on his machine. We thought it was different config, but
 now I can verify that the problem is reproducible here with the default
 configuration (plus CONFIG_SATA_VITESSE).
 
 Hi Bernhard and Tony,
 
 I started seeing this problem, and it affected A4700 in addition to
 A350.
 
 It was not clear the system hang was related to this problem. I saw a
 kdump kernel hang at cpu_init() at an A350, and a hang in find_memory
 on handling pernode space thing at an A4700. No error records and no
 backtrace, so i did not relate my problem to this one at first.
 
 Out of curiosity, i backed out Tony's patch mentioned from 2.6.27-rc5
 and the kdump kernel hangs were gone on both systems.
 
 Also, i had a kdump kernel MCA problem that was caused by kexec
 underallocating kernel memory for the kdump kernel. The  problem
 does not happen again after i backed out the patch.

Tony and Simon,

The program headers (PT_LOAD) of vmlinux before Tony's patch look
like these:

Program Headers:
Type Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
LOAD 0x0001 0xa001 0x0400
 0x00d04480 0x00d04480  RWE1
LOAD 0x00d2 0x 0x04d1
 0x9620 0x9620  RW 1
LOAD 0x00d3 0xa00100d2 0x04d2
 0x000bef50 0x00564c90  RW 1

The program headers of vmlinux after Tony's patch look like
these:
Program Headers:
Type Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
LOAD 0x0001 0xa001 0x0400
 0x00d04480 0x00d04480  RWE1
LOAD 0x00d2 0x 0x04d2
 0x9620 0x9620  RW 1
LOAD 0x00d3 0xa00100d3 0x04d3
 0x000bef58 0x00564c90  RW 1

The first PT_LOAD is for code, the second for percpu, and the
third for data. The FileSiz and MemSiz of the code and percpu
headers in both cases are identical. The only difference is the
PhyAddr of the percpu header after the patch is 0x1 greater
than in the case of before patch.

Tony's patch put per-cpu area for cpu0 in the vmlinux itself
(in the percpu section of the ELF executable). If i read the
code correctly, he added extra PERCPU_PAGE_SIZE (0x1 in ia64)
to the code segment. That explains why the PhysAddr of the percpu
segment became 0x1 greater after the patch.

Howver, shouldn't the MemSiz of the code segment 0x1 larger?
The current logic of add_loaded_segments_info() in
kexec/arch/ia64/crashdump-ia64.c counts on that information to
correctly determine how much memory is needed for vmlinux.

I could not figure out how the MemSiz of the code PL_LOAD
header in vmlinux is determined and set.

Regards,
 - jay

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump broken on Altix 350

2008-09-10 Thread Bernhard Walle 
* Luck, Tony [EMAIL PROTECTED] [2008-08-29]: 

  your commit
 
  commit 10617bbe84628eb18ab5f723d3ba35005adde143
  Author: Tony Luck [EMAIL PROTECTED]
  Date:   Tue Aug 12 10:34:20 2008 -0700
 
  [IA64] Ensure cpu0 can access per-cpu variables in early boot
  code
 
  broke kdump on our Altix 350. I get following early crash in kdump
  kernel
 
 Sorry about that.  I'll try to reproduce it here.

I had some discussion about that with Jay Lan that he could not
reproduce that on his machine. We thought it was different config, but
now I can verify that the problem is reproducible here with the default
configuration (plus CONFIG_SATA_VITESSE).


Bernhard

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump broken on Altix 350

2008-09-10 Thread Bernhard Walle 
* Bernhard Walle [EMAIL PROTECTED] [2008-08-29]: 

 broke kdump on our Altix 350. I get following early crash in kdump
 kernel:

Just as side note: I still have the problem with 2.6.27-rc6.


Bernhard

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump broken on Altix 350

2008-09-10 Thread Jay Lan 
Bernhard Walle wrote:
 * Luck, Tony [EMAIL PROTECTED] [2008-08-29]: 
 
 your commit

 commit 10617bbe84628eb18ab5f723d3ba35005adde143
 Author: Tony Luck [EMAIL PROTECTED]
 Date:   Tue Aug 12 10:34:20 2008 -0700

 [IA64] Ensure cpu0 can access per-cpu variables in early boot
 code

 broke kdump on our Altix 350. I get following early crash in kdump
 kernel
 Sorry about that.  I'll try to reproduce it here.
 
 I had some discussion about that with Jay Lan that he could not
 reproduce that on his machine. We thought it was different config, but
 now I can verify that the problem is reproducible here with the default
 configuration (plus CONFIG_SATA_VITESSE).

Hi Bernhard and Tony,

I started seeing this problem, and it affected A4700 in addition to
A350.

It was not clear the system hang was related to this problem. I saw a
kdump kernel hang at cpu_init() at an A350, and a hang in find_memory
on handling pernode space thing at an A4700. No error records and no
backtrace, so i did not relate my problem to this one at first.

Out of curiosity, i backed out Tony's patch mentioned from 2.6.27-rc5
and the kdump kernel hangs were gone on both systems.

Also, i had a kdump kernel MCA problem that was caused by kexec
underallocating kernel memory for the kdump kernel. The  problem
does not happen again after i backed out the patch.

Regards,
jay

 
 
 Bernhard
 
 ___
 kexec mailing list
 kexec@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump broken on Altix 350

2008-08-29 Thread Luck, Tony 
 your commit

 commit 10617bbe84628eb18ab5f723d3ba35005adde143
 Author: Tony Luck [EMAIL PROTECTED]
 Date:   Tue Aug 12 10:34:20 2008 -0700

 [IA64] Ensure cpu0 can access per-cpu variables in early boot code

 broke kdump on our Altix 350. I get following early crash in kdump
 kernel

Sorry about that.  I'll try to reproduce it here.  Do you (or anyone
else reading this) know if the version of kexec that ships with RHEL5.2
works with current 2.6.27-rc kernels (perhaps not a politically correct
question to ask someone with a @suse.de address :-)

-Tony

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump broken on Altix 350

2008-08-29 Thread Bernhard Walle 
Am Fr 29 Aug 2008 22:42:40 CEST schrieb Luck, Tony [EMAIL PROTECTED]:
 your commit

 commit 10617bbe84628eb18ab5f723d3ba35005adde143
 Author: Tony Luck [EMAIL PROTECTED]
 Date:   Tue Aug 12 10:34:20 2008 -0700

 [IA64] Ensure cpu0 can access per-cpu variables in early boot code

 broke kdump on our Altix 350. I get following early crash in kdump
 kernel

 Sorry about that.  I'll try to reproduce it here.  Do you (or anyone
 else reading this) know if the version of kexec that ships with RHEL5.2
 works with current 2.6.27-rc kernels

There's the danger of a zero-size /proc/vmcore, but that doesn't  
matter here. If you get a /proc/vmcore, regardless of the size, the  
bug did not hit you. :-)
So you can use it here.


Bernhard


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec