* crash with xen/stable-2.6.32.x
@ 2010-04-01 21:54 M A Young
2010-04-01 22:51 ` Jeremy Fitzhardinge
0 siblings, 1 reply; 4+ messages in thread
From: M A Young @ 2010-04-01 21:54 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1956 bytes --]
One of my machines crashes on boot with a kernel built from
xen/stable-2.6.32.x . I can't capture the full output and annoyingly a
boot on a KVM machine within the same system works but a photo is attached
and the most relevant bit from the crash left on the screen looks to be
RIP [<ffffffff81277e63>] acpi_ds_exec_end_op+0x237/0x3dc
RSP <ffff8800db6fb900>
CR2: 000000000000000a
---[ end trace 5a5d197966b56a2e ]---
Kernel panic - not syncing: Attempted to kill init!
This is on x86_64 . Another machine which is i686 works.
More details
(gdb) x/i 0xffffffff81277e63
0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
and the context is
0xffffffff81277e3d <acpi_ds_exec_end_op+529>:
jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
0xffffffff81277e42 <acpi_ds_exec_end_op+534>:
callq 0xffffffff812794db <acpi_ds_load2_end_op>
0xffffffff81277e47 <acpi_ds_exec_end_op+539>: test %eax,%eax
0xffffffff81277e49 <acpi_ds_exec_end_op+541>:
jne 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
0xffffffff81277e4f <acpi_ds_exec_end_op+547>: mov %r12,%rsi
0xffffffff81277e52 <acpi_ds_exec_end_op+550>: mov %rbx,%rdi
0xffffffff81277e55 <acpi_ds_exec_end_op+553>:
callq 0xffffffff8127758a <acpi_ds_eval_buffer_field_operands>
0xffffffff81277e5a <acpi_ds_exec_end_op+558>:
jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
0xffffffff81277e5f <acpi_ds_exec_end_op+563>: mov (%r12),%rax
0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
0xffffffff81277e67 <acpi_ds_exec_end_op+571>: cmp $0x8,%dx
0xffffffff81277e6b <acpi_ds_exec_end_op+575>:
je 0xffffffff81277e75 <acpi_ds_exec_end_op+585>
0xffffffff81277e6d <acpi_ds_exec_end_op+577>: cmp $0x37,%dx
0xffffffff81277e71 <acpi_ds_exec_end_op+581>:
jne 0xffffffff81277ea7 <acpi_ds_exec_end_op+635>
0xffffffff81277e73 <acpi_ds_exec_end_op+583>:
jmp 0xffffffff81277e95 <acpi_ds_exec_end_op+617>
Michael Young
[-- Attachment #2: Type: IMAGE/jpeg, Size: 362054 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: crash with xen/stable-2.6.32.x
2010-04-01 21:54 crash with xen/stable-2.6.32.x M A Young
@ 2010-04-01 22:51 ` Jeremy Fitzhardinge
2010-04-02 8:06 ` Yu, Ke
0 siblings, 1 reply; 4+ messages in thread
From: Jeremy Fitzhardinge @ 2010-04-01 22:51 UTC (permalink / raw)
To: M A Young; +Cc: xen-devel, Yu, Ke
[ CC: Ke Yu ]
On 04/01/2010 02:54 PM, M A Young wrote:
> One of my machines crashes on boot with a kernel built from
> xen/stable-2.6.32.x . I can't capture the full output and annoyingly a
> boot on a KVM machine within the same system works but a photo is
> attached and the most relevant bit from the crash left on the screen
> looks to be
>
> RIP [<ffffffff81277e63>] acpi_ds_exec_end_op+0x237/0x3dc
> RSP <ffff8800db6fb900>
> CR2: 000000000000000a
> ---[ end trace 5a5d197966b56a2e ]---
> Kernel panic - not syncing: Attempted to kill init!
>
> This is on x86_64 . Another machine which is i686 works.
>
> More details
> (gdb) x/i 0xffffffff81277e63
> 0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
> and the context is
> 0xffffffff81277e3d <acpi_ds_exec_end_op+529>:
> jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> 0xffffffff81277e42 <acpi_ds_exec_end_op+534>:
> callq 0xffffffff812794db <acpi_ds_load2_end_op>
> 0xffffffff81277e47 <acpi_ds_exec_end_op+539>: test %eax,%eax
> 0xffffffff81277e49 <acpi_ds_exec_end_op+541>:
> jne 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> 0xffffffff81277e4f <acpi_ds_exec_end_op+547>: mov %r12,%rsi
> 0xffffffff81277e52 <acpi_ds_exec_end_op+550>: mov %rbx,%rdi
> 0xffffffff81277e55 <acpi_ds_exec_end_op+553>:
> callq 0xffffffff8127758a <acpi_ds_eval_buffer_field_operands>
> 0xffffffff81277e5a <acpi_ds_exec_end_op+558>:
> jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> 0xffffffff81277e5f <acpi_ds_exec_end_op+563>: mov (%r12),%rax
> 0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
> 0xffffffff81277e67 <acpi_ds_exec_end_op+571>: cmp $0x8,%dx
> 0xffffffff81277e6b <acpi_ds_exec_end_op+575>:
> je 0xffffffff81277e75 <acpi_ds_exec_end_op+585>
> 0xffffffff81277e6d <acpi_ds_exec_end_op+577>: cmp $0x37,%dx
> 0xffffffff81277e71 <acpi_ds_exec_end_op+581>:
> jne 0xffffffff81277ea7 <acpi_ds_exec_end_op+635>
> 0xffffffff81277e73 <acpi_ds_exec_end_op+583>:
> jmp 0xffffffff81277e95 <acpi_ds_exec_end_op+617>
>
> Michael Young
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: crash with xen/stable-2.6.32.x
2010-04-01 22:51 ` Jeremy Fitzhardinge
@ 2010-04-02 8:06 ` Yu, Ke
2010-04-02 16:22 ` M A Young
0 siblings, 1 reply; 4+ messages in thread
From: Yu, Ke @ 2010-04-02 8:06 UTC (permalink / raw)
To: Jeremy Fitzhardinge, M A Young; +Cc: xen-devel@lists.xensource.com
>From the screen phone, it shows panic when evaluating acpi processor "_CST" to get ACPI C state info.
It is a bit strange, since most of the xen acpi processor panic is caused by incorrect processor id (pr->id), the ACPI method evaluation (like "_CST" here) should not relate to this.
BTW, does xen/master branch or bare mental works in this machine? And in the i686 box that works, can 'xenpm get-cpuidle-state' show correct Cx information?
Best Regards
Ke
> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
> Sent: Friday, April 02, 2010 6:51 AM
> To: M A Young
> Cc: xen-devel@lists.xensource.com; Yu, Ke
> Subject: Re: [Xen-devel] crash with xen/stable-2.6.32.x
>
> [ CC: Ke Yu ]
>
> On 04/01/2010 02:54 PM, M A Young wrote:
> > One of my machines crashes on boot with a kernel built from
> > xen/stable-2.6.32.x . I can't capture the full output and annoyingly a
> > boot on a KVM machine within the same system works but a photo is
> > attached and the most relevant bit from the crash left on the screen
> > looks to be
> >
> > RIP [<ffffffff81277e63>] acpi_ds_exec_end_op+0x237/0x3dc
> > RSP <ffff8800db6fb900>
> > CR2: 000000000000000a
> > ---[ end trace 5a5d197966b56a2e ]---
> > Kernel panic - not syncing: Attempted to kill init!
> >
> > This is on x86_64 . Another machine which is i686 works.
> >
> > More details
> > (gdb) x/i 0xffffffff81277e63
> > 0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
> > and the context is
> > 0xffffffff81277e3d <acpi_ds_exec_end_op+529>:
> > jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> > 0xffffffff81277e42 <acpi_ds_exec_end_op+534>:
> > callq 0xffffffff812794db <acpi_ds_load2_end_op>
> > 0xffffffff81277e47 <acpi_ds_exec_end_op+539>: test %eax,%eax
> > 0xffffffff81277e49 <acpi_ds_exec_end_op+541>:
> > jne 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> > 0xffffffff81277e4f <acpi_ds_exec_end_op+547>: mov %r12,%rsi
> > 0xffffffff81277e52 <acpi_ds_exec_end_op+550>: mov %rbx,%rdi
> > 0xffffffff81277e55 <acpi_ds_exec_end_op+553>:
> > callq 0xffffffff8127758a <acpi_ds_eval_buffer_field_operands>
> > 0xffffffff81277e5a <acpi_ds_exec_end_op+558>:
> > jmpq 0xffffffff81277f7f <acpi_ds_exec_end_op+851>
> > 0xffffffff81277e5f <acpi_ds_exec_end_op+563>: mov (%r12),%rax
> > 0xffffffff81277e63 <acpi_ds_exec_end_op+567>: mov 0xa(%rax),%dx
> > 0xffffffff81277e67 <acpi_ds_exec_end_op+571>: cmp $0x8,%dx
> > 0xffffffff81277e6b <acpi_ds_exec_end_op+575>:
> > je 0xffffffff81277e75 <acpi_ds_exec_end_op+585>
> > 0xffffffff81277e6d <acpi_ds_exec_end_op+577>: cmp $0x37,%dx
> > 0xffffffff81277e71 <acpi_ds_exec_end_op+581>:
> > jne 0xffffffff81277ea7 <acpi_ds_exec_end_op+635>
> > 0xffffffff81277e73 <acpi_ds_exec_end_op+583>:
> > jmp 0xffffffff81277e95 <acpi_ds_exec_end_op+617>
> >
> > Michael Young
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: crash with xen/stable-2.6.32.x
2010-04-02 8:06 ` Yu, Ke
@ 2010-04-02 16:22 ` M A Young
0 siblings, 0 replies; 4+ messages in thread
From: M A Young @ 2010-04-02 16:22 UTC (permalink / raw)
To: Yu, Ke; +Cc: Jeremy Fitzhardinge, xen-devel@lists.xensource.com
On Fri, 2 Apr 2010, Yu, Ke wrote:
> BTW, does xen/master branch or bare mental works in this machine? And in
> the i686 box that works, can 'xenpm get-cpuidle-state' show correct Cx
> information?
Running the same kernel without the xen hypervisor gives the warning below
though the system appears to function normally.
I can run a xen kernel built from xen/stable from about a week ago as a
dom0, and that gives for xenpm get-cpuidle-state
Max C-state: C7
cpu id : 0
total C-states : 0
idle time(ms) : 0
cpu id : 1
total C-states : 0
idle time(ms) : 0
Michael Young
Apr 2 15:17:39 localhost kernel: ACPI: SSDT 00000000df66e4b4 002C8 (v01
PmRef
Cpu0Ist 00003000 INTL 20050624)
Apr 2 15:17:39 localhost kernel: ACPI: SSDT 00000000df66de4a 005E5 (v01
PmRef
Cpu0Cst 00003001 INTL 20050624)
Apr 2 15:17:39 localhost kernel: Marking TSC unstable due to TSC halts in
idle
Apr 2 15:17:39 localhost kernel: processor LNXCPU:00: registered as
cooling_dev
ice0
Apr 2 15:17:39 localhost kernel: ------------[ cut here ]------------
Apr 2 15:17:39 localhost kernel: WARNING: at mm/page_alloc.c:1820
__alloc_pages
_nodemask+0x174/0x631()
Apr 2 15:17:39 localhost kernel: Hardware name: Inspiron 1525
Apr 2 15:17:39 localhost kernel: Modules linked in:
Apr 2 15:17:39 localhost kernel: Pid: 1, comm: swapper Not tainted
2.6.32.10-1.
2.96.xendom0.fc12.x86_64 #1
Apr 2 15:17:39 localhost kernel: Call Trace:
Apr 2 15:17:39 localhost kernel: [<ffffffff81057320>]
warn_slowpath_common+0x7c
/0x94
Apr 2 15:17:39 localhost kernel: [<ffffffff8105734c>]
warn_slowpath_null+0x14/0
x16
Apr 2 15:17:39 localhost kernel: [<ffffffff810dd59b>]
__alloc_pages_nodemask+0x
174/0x631
Apr 2 15:17:39 localhost kernel: [<ffffffff81038005>] ?
__ioremap_caller+0x294/
0x2fa
Apr 2 15:17:39 localhost kernel: [<ffffffff81105f47>]
alloc_page_interleave+0x3
9/0x86
Apr 2 15:17:39 localhost kernel: [<ffffffff81106046>]
alloc_pages_current+0x6c/
0x9e
Apr 2 15:17:39 localhost kernel: [<ffffffff810dc26e>]
__get_free_pages+0xe/0x4b
Apr 2 15:17:39 localhost kernel: [<ffffffff8110f114>]
__kmalloc+0x47/0x15e
Apr 2 15:17:39 localhost kernel: [<ffffffff8127dead>] ?
acpi_ex_load_op+0xc2/0x
265
Apr 2 15:17:39 localhost kernel: [<ffffffff8127dd51>]
acpi_os_allocate+0x2a/0x2
c
Apr 2 15:17:39 localhost kernel: [<ffffffff8127dec8>]
acpi_ex_load_op+0xdd/0x26
5
Apr 2 15:17:39 localhost kernel: [<ffffffff81280945>]
acpi_ex_opcode_1A_1T_0R+0
x2a/0x50
Apr 2 15:17:39 localhost kernel: [<ffffffff81277d1b>]
acpi_ds_exec_end_op+0xef/
0x3dc
Apr 2 15:17:39 localhost kernel: [<ffffffff8128a49e>]
acpi_ps_parse_loop+0x7c0/
0x946
Apr 2 15:17:39 localhost kernel: [<ffffffff81278611>] ?
acpi_ds_call_control_me
thod+0x16b/0x1da
Apr 2 15:17:39 localhost kernel: [<ffffffff81289588>]
acpi_ps_parse_aml+0x9f/0x
2de
Apr 2 15:17:39 localhost kernel: [<ffffffff8128ad2c>]
acpi_ps_execute_method+0x
1e9/0x2b9
Apr 2 15:17:39 localhost kernel: [<ffffffff8128628a>]
acpi_ns_evaluate+0xe6/0x1
ad
Apr 2 15:17:39 localhost kernel: [<ffffffff81285cb0>]
acpi_evaluate_object+0xfe
/0x1f7
Apr 2 15:17:39 localhost kernel: [<ffffffff81026b34>] ?
init_intel_pdc+0xd6/0x1
7d
Apr 2 15:17:39 localhost kernel: [<ffffffff81292983>]
acpi_processor_set_pdc+0x
41/0x43
Apr 2 15:17:39 localhost kernel: [<ffffffff8145b0fb>]
acpi_processor_add+0x579/
0x6a4
Apr 2 15:17:39 localhost kernel: [<ffffffff8126e72d>]
acpi_device_probe+0x50/0x
122
Apr 2 15:17:39 localhost kernel: [<ffffffff812e48a2>]
driver_probe_device+0xea/
0x217
Apr 2 15:17:39 localhost kernel: [<ffffffff812e4a2c>]
__driver_attach+0x5d/0x81
Apr 2 15:17:39 localhost kernel: [<ffffffff812e49cf>] ?
__driver_attach+0x0/0x8
1
Apr 2 15:17:39 localhost kernel: [<ffffffff812e3cb4>]
bus_for_each_dev+0x53/0x8
8
Apr 2 15:17:39 localhost kernel: [<ffffffff812e4632>]
driver_attach+0x1e/0x20
Apr 2 15:17:39 localhost kernel: [<ffffffff812e4272>]
bus_add_driver+0xf7/0x25d
Apr 2 15:17:39 localhost kernel: [<ffffffff812e4d2c>]
driver_register+0x9d/0x10
e
Apr 2 15:17:39 localhost kernel: [<ffffffff81852666>] ?
acpi_processor_init+0x0
/0x136
Apr 2 15:17:39 localhost kernel: [<ffffffff8126fe18>]
acpi_bus_register_driver+
0x43/0x47
Apr 2 15:17:39 localhost kernel: [<ffffffff81852726>]
acpi_processor_init+0xc0/
0x136
Apr 2 15:17:39 localhost kernel: [<ffffffff81852662>] ?
acpi_pci_slot_init+0x1c
/0x20
Apr 2 15:17:39 localhost kernel: [<ffffffff8100a069>]
do_one_initcall+0x5e/0x15
9
Apr 2 15:17:39 localhost kernel: [<ffffffff81824766>]
kernel_init+0x20f/0x269
Apr 2 15:17:39 localhost kernel: [<ffffffff81013d6a>] child_rip+0xa/0x20
Apr 2 15:17:39 localhost kernel: [<ffffffff81824557>] ?
kernel_init+0x0/0x269
Apr 2 15:17:39 localhost kernel: [<ffffffff81013d60>] ?
child_rip+0x0/0x20
Apr 2 15:17:39 localhost kernel: ---[ end trace 5a5d197966b56a2e ]---
Apr 2 15:17:39 localhost kernel: ACPI Error (psparse-0537):
Apr 2 15:17:39 localhost kernel: Switching to clocksource hpet
Apr 2 15:17:39 localhost kernel: Method parse/execution failed
[\_PR_.CPU1._OSC
] (Node ffff88011ba6e000), AE_NO_MEMORY
Apr 2 15:17:39 localhost kernel: ACPI Error (psparse-0537): Method
parse/execut
ion failed [\_PR_.CPU1._PDC] (Node ffff88011ba63fe0), AE_NO_MEMORY
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-04-02 16:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-01 21:54 crash with xen/stable-2.6.32.x M A Young
2010-04-01 22:51 ` Jeremy Fitzhardinge
2010-04-02 8:06 ` Yu, Ke
2010-04-02 16:22 ` M A Young
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.