* [PATCH 00/02] Kexec / Kdump: ia64 build fixes
@ 2006-12-04 4:35 Magnus Damm
2006-12-04 4:35 ` [PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN() Magnus Damm
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Magnus Damm @ 2006-12-04 4:35 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, magnus.damm, Akio Takebe, Magnus Damm, Alex Williamson
[PATCH 00/02] Kexec / Kdump: ia64 build fixes
The recently merged kexec / kdump patches unfortunately break the build on
ia64. Sorry about that. With the following patches the kexec / kdump code
in the hypervisor builds properly on ia64. The patches are tested using
xen-unstable.hg 12717 on x86_32 and x86_64 and with the ia64 tree kindly
provided by Alex Williamson.
Please apply.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN()
2006-12-04 4:35 [PATCH 00/02] Kexec / Kdump: ia64 build fixes Magnus Damm
@ 2006-12-04 4:35 ` Magnus Damm
2006-12-04 4:35 ` [PATCH 02/02] Kexec / Kdump: Don't declare _end Magnus Damm
2006-12-04 9:18 ` [PATCH 00/02] Kexec / Kdump: ia64 build fixes Ian Campbell
2 siblings, 0 replies; 6+ messages in thread
From: Magnus Damm @ 2006-12-04 4:35 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, magnus.damm, Akio Takebe, Magnus Damm, Alex Williamson
[PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN()
ALIGN() is already defined in xen/include/asm-ia64/config.h. This patch
renames ALIGN() to NOTE_ALIGN() to make the kexec code build on ia64.
Signed-Off-By: Magnus Damm <magnus@valinux.co.jp>
---
Applies on top of xen-unstable-12717.
xen/include/xen/elfcore.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 0001/xen/include/xen/elfcore.h
+++ work/xen/include/xen/elfcore.h 2006-12-04 13:04:03.000000000 +0900
@@ -71,8 +71,8 @@ typedef struct
* That requires infrastructure. Let's not.
*/
-#define ALIGN(x, n) ((x + ((1 << n) - 1)) / (1 << n))
-#define PAD32(x) u32 pad_data[ALIGN(x, 2)]
+#define NOTE_ALIGN(x, n) ((x + ((1 << n) - 1)) / (1 << n))
+#define PAD32(x) u32 pad_data[NOTE_ALIGN(x, 2)]
#define TYPEDEF_NOTE(type, strlen, desctype) \
typedef struct { \
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 02/02] Kexec / Kdump: Don't declare _end
2006-12-04 4:35 [PATCH 00/02] Kexec / Kdump: ia64 build fixes Magnus Damm
2006-12-04 4:35 ` [PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN() Magnus Damm
@ 2006-12-04 4:35 ` Magnus Damm
2006-12-04 17:45 ` Ian Campbell
2006-12-04 9:18 ` [PATCH 00/02] Kexec / Kdump: ia64 build fixes Ian Campbell
2 siblings, 1 reply; 6+ messages in thread
From: Magnus Damm @ 2006-12-04 4:35 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, magnus.damm, Akio Takebe, Magnus Damm, Alex Williamson
[PATCH 02/02] Kexec / Kdump: Don't declare _end
_end is already declared in xen/include/asm/config.h, so don't declare
it twice. This solves a powerpc/ia64 build problem where _end is declared
as char _end[] compared to unsigned long _end on x86.
Signed-Off-By: Magnus Damm <magnus@valinux.co.jp>
---
Applies on top of xen-unstable-12717.
xen/common/kexec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 0001/xen/common/kexec.c
+++ work/xen/common/kexec.c 2006-12-04 12:45:57.000000000 +0900
@@ -158,7 +158,7 @@ static int kexec_get_reserve(xen_kexec_r
return 0;
}
-extern unsigned long _text, _end;
+extern unsigned long _text;
static int kexec_get_xen(xen_kexec_range_t *range, int get_ma)
{
@@ -167,7 +167,7 @@ static int kexec_get_xen(xen_kexec_range
else
range->start = (unsigned long) &_text;
- range->size = &_end - &_text;
+ range->size = (unsigned long)&_end - (unsigned long)&_text;
return 0;
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 00/02] Kexec / Kdump: ia64 build fixes
2006-12-04 4:35 [PATCH 00/02] Kexec / Kdump: ia64 build fixes Magnus Damm
2006-12-04 4:35 ` [PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN() Magnus Damm
2006-12-04 4:35 ` [PATCH 02/02] Kexec / Kdump: Don't declare _end Magnus Damm
@ 2006-12-04 9:18 ` Ian Campbell
2 siblings, 0 replies; 6+ messages in thread
From: Ian Campbell @ 2006-12-04 9:18 UTC (permalink / raw)
To: Magnus Damm; +Cc: Akio Takebe, xen-devel, magnus.damm, Alex Williamson
On Mon, 2006-12-04 at 13:35 +0900, Magnus Damm wrote:
> [PATCH 00/02] Kexec / Kdump: ia64 build fixes
>
> The recently merged kexec / kdump patches unfortunately break the build on
> ia64. Sorry about that. With the following patches the kexec / kdump code
> in the hypervisor builds properly on ia64. The patches are tested using
> xen-unstable.hg 12717 on x86_32 and x86_64 and with the ia64 tree kindly
> provided by Alex Williamson.
>
> Please apply.
Applied. Thanks.
Ian.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 02/02] Kexec / Kdump: Don't declare _end
2006-12-04 4:35 ` [PATCH 02/02] Kexec / Kdump: Don't declare _end Magnus Damm
@ 2006-12-04 17:45 ` Ian Campbell
2006-12-05 6:55 ` Magnus Damm
0 siblings, 1 reply; 6+ messages in thread
From: Ian Campbell @ 2006-12-04 17:45 UTC (permalink / raw)
Cc: xen-devel, magnus.damm, Akio Takebe, Magnus Damm, Alex Williamson
Hey Magnus,
On Mon, 2006-12-04 at 13:35 +0900, Magnus Damm wrote:
> [PATCH 02/02] Kexec / Kdump: Don't declare _end
>
> _end is already declared in xen/include/asm/config.h, so don't declare
> it twice. This solves a powerpc/ia64 build problem where _end is declared
> as char _end[] compared to unsigned long _end on x86.
This change has broken x86 kdump :-( I think because you fixed a bug
with your change and thereby uncovered an another latent bug.
Before the range->size returned from kexec_get_xen() was 1/4 of the
correct value because you were subtracting unsigned long * pointers so
size was the number of words not the number of bytes as expected. After
this change we are now subtracting unsigned longs so the correct value
is returned.
This seems to have caused the crash notes to disappear from /proc/iomem:
Before:
00100000-def7efff : System RAM
00100000-001397bf : Hypervisor code and data
00193000-001930f7 : Crash note
00194000-001940f7 : Crash note
02000000-05ffffff : Crash kernel
After:
00100000-def7efff : System RAM
00100000-001e5eff : Hypervisor code and data
02000000-05ffffff : Crash kernel
I presume they went missing because "Hypervisor code and data" now
overlaps the notes.
For some reason this has broken kdump for me (on x86_32p). The kdump
kernel gives this stack trace and then hangs a little later on:
general protection fault: 0000 [#1]
Modules linked in:
CPU: 0
EIP: 0060:[<c204954d>] Not tainted VLI
EFLAGS: 00010002 (2.6.16.33-x86_32p-kdump #17)
EIP is at free_block+0x6d/0x100
eax: 00000000 ebx: ffffffff ecx: ffffffff edx: c2455000
esi: 00000001 edi: c5f22540 ebp: c253bef0 esp: c253bed8
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 4, threadinfo=c253a000 task=c5f0aa70)
Stack: <0>00000001 c5e71210 00000000 c5e71210 00000001 c5e71200 c253bf14 c2049625
00000000 c234b100 c5f0aa70 c5f22540 c5f22588 c5f22540 c257a4c0 c253bf34
c204a796 00000000 00000086 00000000 c242d364 c5f51680 00000296 c253bf64
Call Trace:
[<c2003685>] show_stack_log_lvl+0xc5/0xf0
[<c2003847>] show_registers+0x197/0x220
[<c20039ae>] die+0xde/0x210
[<c20048fe>] do_general_protection+0xee/0x1a0
[<c200310f>] error_code+0x4f/0x54
[<c2049625>] drain_array_locked+0x45/0xa0
[<c204a796>] cache_reap+0x66/0x130
[<c2021456>] run_workqueue+0x66/0xd0
[<c2021a08>] worker_thread+0x138/0x160
[<c202461f>] kthread+0xaf/0xe0
[<c2001005>] kernel_thread_helper+0x5/0x10
I changed xen_machine_kexec_register_resources() on the Linux side to
correctly nest the crash note resources under the xen resource which has
fixed things for me. Does the change below make sense to you? If so I'll
commit.
As a secondary point, perhaps the hypervisor resource should go all the
way to the end of the Xen heap (xenheap_phys_end I think) rather than
just the the end of .data/.bss?
Ian.
diff -r a0da9727b51d linux-2.6-xen-sparse/drivers/xen/core/machine_kexec.c
--- a/linux-2.6-xen-sparse/drivers/xen/core/machine_kexec.c Mon Dec 04 09:55:06 2006 +0000
+++ b/linux-2.6-xen-sparse/drivers/xen/core/machine_kexec.c Mon Dec 04 17:32:35 2006 +0000
@@ -106,7 +106,7 @@ void xen_machine_kexec_register_resource
request_resource(res, &xen_hypervisor_res);
for (k = 0; k < xen_max_nr_phys_cpus; k++)
- request_resource(res, xen_phys_cpus + k);
+ request_resource(&xen_hypervisor_res, xen_phys_cpus + k);
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 02/02] Kexec / Kdump: Don't declare _end
2006-12-04 17:45 ` Ian Campbell
@ 2006-12-05 6:55 ` Magnus Damm
0 siblings, 0 replies; 6+ messages in thread
From: Magnus Damm @ 2006-12-05 6:55 UTC (permalink / raw)
To: Ian Campbell; +Cc: Magnus Damm, xen-devel, Akio Takebe, Alex Williamson
Hi again Ian,
On 12/5/06, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> Hey Magnus,
>
> On Mon, 2006-12-04 at 13:35 +0900, Magnus Damm wrote:
> > [PATCH 02/02] Kexec / Kdump: Don't declare _end
> >
> > _end is already declared in xen/include/asm/config.h, so don't declare
> > it twice. This solves a powerpc/ia64 build problem where _end is declared
> > as char _end[] compared to unsigned long _end on x86.
>
> This change has broken x86 kdump :-( I think because you fixed a bug
> with your change and thereby uncovered an another latent bug.
Yes, you are right. Thanks for noticing and cooking up a fix.
> Before the range->size returned from kexec_get_xen() was 1/4 of the
> correct value because you were subtracting unsigned long * pointers so
> size was the number of words not the number of bytes as expected. After
> this change we are now subtracting unsigned longs so the correct value
> is returned.
>
> This seems to have caused the crash notes to disappear from /proc/iomem:
> Before:
> 00100000-def7efff : System RAM
> 00100000-001397bf : Hypervisor code and data
> 00193000-001930f7 : Crash note
> 00194000-001940f7 : Crash note
> 02000000-05ffffff : Crash kernel
> After:
> 00100000-def7efff : System RAM
> 00100000-001e5eff : Hypervisor code and data
> 02000000-05ffffff : Crash kernel
>
> I presume they went missing because "Hypervisor code and data" now
> overlaps the notes.
Your reasoning makes sense, this indeed looks like a problem related to overlap.
> For some reason this has broken kdump for me (on x86_32p). The kdump
> kernel gives this stack trace and then hangs a little later on:
> general protection fault: 0000 [#1]
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c204954d>] Not tainted VLI
> EFLAGS: 00010002 (2.6.16.33-x86_32p-kdump #17)
> EIP is at free_block+0x6d/0x100
> eax: 00000000 ebx: ffffffff ecx: ffffffff edx: c2455000
> esi: 00000001 edi: c5f22540 ebp: c253bef0 esp: c253bed8
> ds: 007b es: 007b ss: 0068
> Process events/0 (pid: 4, threadinfo=c253a000 task=c5f0aa70)
> Stack: <0>00000001 c5e71210 00000000 c5e71210 00000001 c5e71200 c253bf14 c2049625
> 00000000 c234b100 c5f0aa70 c5f22540 c5f22588 c5f22540 c257a4c0 c253bf34
> c204a796 00000000 00000086 00000000 c242d364 c5f51680 00000296 c253bf64
> Call Trace:
> [<c2003685>] show_stack_log_lvl+0xc5/0xf0
> [<c2003847>] show_registers+0x197/0x220
> [<c20039ae>] die+0xde/0x210
> [<c20048fe>] do_general_protection+0xee/0x1a0
> [<c200310f>] error_code+0x4f/0x54
> [<c2049625>] drain_array_locked+0x45/0xa0
> [<c204a796>] cache_reap+0x66/0x130
> [<c2021456>] run_workqueue+0x66/0xd0
> [<c2021a08>] worker_thread+0x138/0x160
> [<c202461f>] kthread+0xaf/0xe0
> [<c2001005>] kernel_thread_helper+0x5/0x10
I have not investigated your stack trace, but there are no crash notes
present in /proc/iomem without your patch which will lead to a vmcore
without PT_NOTE. This may trigger all sorts of errors in the secondary
kernel, but I'm not sure exactly which.
> I changed xen_machine_kexec_register_resources() on the Linux side to
> correctly nest the crash note resources under the xen resource which has
> fixed things for me. Does the change below make sense to you? If so I'll
> commit.
The patch looks good, please commit. I've tested it and the crash
notes now show up in /proc/iomem as expected. Thank you.
> As a secondary point, perhaps the hypervisor resource should go all the
> way to the end of the Xen heap (xenheap_phys_end I think) rather than
> just the the end of .data/.bss?
Sounds like a good idea. I'm currently thinking how to pass down
virtual addresses from the hypervisor down to userspace so I can
modify kexec-tools to use proper virtual addresses for the PT_LOAD
program headers. I need the virtual address to make use of the
hypervisor resource, so they are sort of connected together. Anyway,
using the end of the Xen heap sounds like a step in the right
direction.
Many thanks,
/ magnus
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-12-05 6:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-04 4:35 [PATCH 00/02] Kexec / Kdump: ia64 build fixes Magnus Damm
2006-12-04 4:35 ` [PATCH 01/02] Kexec / Kdump: Use NOTE_ALIGN() instead of ALIGN() Magnus Damm
2006-12-04 4:35 ` [PATCH 02/02] Kexec / Kdump: Don't declare _end Magnus Damm
2006-12-04 17:45 ` Ian Campbell
2006-12-05 6:55 ` Magnus Damm
2006-12-04 9:18 ` [PATCH 00/02] Kexec / Kdump: ia64 build fixes Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.