[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] stack corruption creating idle domain
I've been debugging a hang that I see on current xen-unstable.hg and I'm looking for suggestions. The hang occurs just after xen prints "About to call scheduler_init()". I've traced the problem with ski and it appears that in init_switch_stack we blow away the stack with the memset of the switch_stack and pt_regs area. The problem seems to be that we're setting idle_vcpu[0] to the address in r13 (back in start_kernel), but we haven't set r13 to anything that necessarily has enough space for idle_vcpu[0]. Am I missing the setup of r13? The trivial patch below works around the problem, but perhaps I'm overlooking some intricacy about how this is supposed to work. BTW, I only see this problem when using gcc-3.3.5. That compiler decides to use the stack in init_switch_stack causing us to infinitely page fault when we get back from the memset. I have observed in ski that a xen image compiled with gcc-4.0 also overwrites the stack, but nothing critical seems to be using it. What's the correct fix here? Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab --- a/xen/arch/ia64/xen/xensetup.c Mon Jan 23 15:27:00 2006 +++ b/xen/arch/ia64/xen/xensetup.c Tue Jan 24 05:59:04 2006 @@ -148,6 +148,8 @@ .stop_bits = 1 }; +struct vcpu idlevcpu0; + void start_kernel(void) { unsigned char *cmdline; @@ -280,7 +282,8 @@ printk("About to call scheduler_init()\n"); scheduler_init(); - idle_vcpu[0] = (struct vcpu*) ia64_r13; + ia64_r13 = (void *)&idlevcpu0; + idle_vcpu[0] = &idlevcpu0; idle_domain = domain_create(IDLE_DOMAIN_ID, 0); BUG_ON(idle_domain == NULL); _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |