* pv_ops dom0 attempt
@ 2009-09-18 20:03 Christopher S. Aker
2009-09-19 0:27 ` Jeremy Fitzhardinge
0 siblings, 1 reply; 3+ messages in thread
From: Christopher S. Aker @ 2009-09-18 20:03 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: xen-devel >> xen devel
Decided to give pv_ops dom0 another go (from a few weeks ago). Does
pv_ops dom0 require an unstable hypervisor? Here's what I get with a 64
bit 3.4.1 hypervisor and a dom0 kernel from a a recent clone of
rebase/master:
BUG: unable to handle kernel paging request at 82c64bbd
IP: [<c14ad4cd>] acpi_processor_start+0x50d/0x762
*pdpt = 00000009256e7007
Oops: 0002 [#1] SMP
last sysfs file:
Modules linked in:
Pid: 1, comm: swapper Not tainted (2.6.31-pvops-1-01410-gebf47a1-dirty
#1) X8DTU
EIP: 0061:[<c14ad4cd>] EFLAGS: 00010246 CPU: 0
EIP is at acpi_processor_start+0x50d/0x762
EAX: c16db580 EBX: d6265800 ECX: d6227400 EDX: c158963d
ESI: ffffffff EDI: d6227428 EBP: d6061e88 ESP: d6061e40
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
Process swapper (pid: 1, ti=d6060000 task=d605fbc0 task.ti=d6060000)
Stack:
d6227400 d6265800 00000000 d70a2462 0000000c 00000008 00000000 00000000
<0> 00000000 00000000 00000002 d6002440 00000000 d6061e50 c1092964 c1653bb8
<0> c1653bb8 d6227400 d6061e9c c129b307 d6227400 c1653bb8 00000000 d6061eb8
Call Trace:
[<c1092964>] ? kmem_cache_alloc+0x54/0xa0
[<c129b307>] ? acpi_start_single_object+0x1e/0x3f
[<c129b511>] ? acpi_device_probe+0x81/0x139
[<c1300449>] ? driver_probe_device+0x69/0x170
[<c14b0181>] ? _spin_unlock_irqrestore+0x21/0x30
[<c13005d1>] ? __driver_attach+0x81/0x90
[<c12ffd7b>] ? bus_for_each_dev+0x5b/0x80
[<c129b3c2>] ? acpi_device_remove+0x0/0xce
[<c13002f9>] ? driver_attach+0x19/0x20
[<c1300550>] ? __driver_attach+0x0/0x90
[<c12ff5fc>] ? bus_add_driver+0xbc/0x260
[<c129b3c2>] ? acpi_device_remove+0x0/0xce
[<c1300855>] ? driver_register+0x75/0x160
[<c129cbbd>] ? acpi_bus_register_driver+0x3a/0x3d
[<c1699e5a>] ? acpi_processor_init+0x86/0xe7
[<c129cbbd>] ? acpi_bus_register_driver+0x3a/0x3d
[<c1699dd4>] ? acpi_processor_init+0x0/0xe7
[<c1002033>] ? do_one_initcall+0x23/0x180
[<c106aa77>] ? init_irq_proc+0x67/0x80
[<c167635d>] ? kernel_init+0x138/0x191
[<c1676225>] ? kernel_init+0x0/0x191
[<c100ab07>] ? kernel_thread_helper+0x7/0x10
Code: 15 68 3f 84 5c c1 bb ed ff ff ff e8 19 08 00 00 5e e9 48 02 00 00
8b 5d bc b8 80 b5 6d c1 8b 4d b8 8b 53 08 8b 14 95 e0 22 67 c1 <89> 0c
10 8b 53 08 b8 84 b5 6d c1 8b 14 95 e0 22 67 c1 89 1c 10
EIP: [<c14ad4cd>] acpi_processor_start+0x50d/0x762 SS:ESP e021:d6061e40
CR2: 0000000082c64bbd
---[ end trace a7919e7f17c0a725 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D
2.6.31-pvops-1-01410-gebf47a1-dirty #1
Call Trace:
[<c14adce3>] ? printk+0x18/0x1a
[<c14adc1b>] panic+0x43/0xf3
[<c1037023>] do_exit+0x5b3/0x680
[<c14adce3>] ? printk+0x18/0x1a
[<c100da28>] oops_end+0xc8/0xd0
[<c1020c26>] no_context+0xb6/0x1a0
[<c1020d6b>] __bad_area_nosemaphore+0x5b/0x170
[<c1005d9a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c1005d9a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10065dc>] ? check_events+0x8/0xc
[<c10065d3>] ? xen_restore_fl_direct_end+0x0/0x1
[<c14b0181>] ? _spin_unlock_irqrestore+0x21/0x30
[<c1005d9a>] ? xen_force_evtchn_callback+0x1a/0x30
[<c10065dc>] ? check_events+0x8/0xc
[<c10065d3>] ? xen_restore_fl_direct_end+0x0/0x1
[<c1091ce4>] ? kfree+0x74/0x90
[<c12ae9a2>] ? acpi_ns_get_node+0x7c/0x86
[<c1020e92>] bad_area_nosemaphore+0x12/0x20
[<c10211d4>] do_page_fault+0x1b4/0x260
[<c1021020>] ? do_page_fault+0x0/0x260
[<c14b045e>] error_code+0x66/0x6c
[<c126007b>] ? as_can_break_anticipation+0xeb/0x2f0
[<c1021020>] ? do_page_fault+0x0/0x260
[<c14ad4cd>] ? acpi_processor_start+0x50d/0x762
[<c1092964>] ? kmem_cache_alloc+0x54/0xa0
[<c129b307>] acpi_start_single_object+0x1e/0x3f
[<c129b511>] acpi_device_probe+0x81/0x139
[<c1300449>] driver_probe_device+0x69/0x170
[<c14b0181>] ? _spin_unlock_irqrestore+0x21/0x30
[<c13005d1>] __driver_attach+0x81/0x90
[<c12ffd7b>] bus_for_each_dev+0x5b/0x80
[<c129b3c2>] ? acpi_device_remove+0x0/0xce
[<c13002f9>] driver_attach+0x19/0x20
[<c1300550>] ? __driver_attach+0x0/0x90
[<c12ff5fc>] bus_add_driver+0xbc/0x260
[<c129b3c2>] ? acpi_device_remove+0x0/0xce
[<c1300855>] driver_register+0x75/0x160
[<c129cbbd>] acpi_bus_register_driver+0x3a/0x3d
[<c1699e5a>] acpi_processor_init+0x86/0xe7
[<c129cbbd>] ? acpi_bus_register_driver+0x3a/0x3d
[<c1699dd4>] ? acpi_processor_init+0x0/0xe7
[<c1002033>] do_one_initcall+0x23/0x180
[<c106aa77>] ? init_irq_proc+0x67/0x80
[<c167635d>] kernel_init+0x138/0x191
[<c1676225>] ? kernel_init+0x0/0x191
[<c100ab07>] kernel_thread_helper+0x7/0x10
Full boot log here: http://p.linode.com/2993
What is the recommended recipe for pv_ops dom0?
-Chris
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: pv_ops dom0 attempt
2009-09-18 20:03 pv_ops dom0 attempt Christopher S. Aker
@ 2009-09-19 0:27 ` Jeremy Fitzhardinge
2009-09-20 12:22 ` Yu, Ke
0 siblings, 1 reply; 3+ messages in thread
From: Jeremy Fitzhardinge @ 2009-09-19 0:27 UTC (permalink / raw)
To: Christopher S. Aker; +Cc: xen-devel >> xen devel, Yu, Ke
On 09/18/09 13:03, Christopher S. Aker wrote:
> Decided to give pv_ops dom0 another go (from a few weeks ago). Does
> pv_ops dom0 require an unstable hypervisor? Here's what I get with a
> 64 bit 3.4.1 hypervisor and a dom0 kernel from a a recent clone of
> rebase/master:
>
> BUG: unable to handle kernel paging request at 82c64bbd
> IP: [<c14ad4cd>] acpi_processor_start+0x50d/0x762
> *pdpt = 00000009256e7007
> Oops: 0002 [#1] SMP
> last sysfs file:
> Modules linked in:
That's novel; I haven't seen that crash before. Could you do a "list
*0xc14ad4cd" to work out what source line it hit. What's your .config?
I wonder if this has to do with the external processor control stuff?
> Full boot log here: http://p.linode.com/2993
>
> What is the recommended recipe for pv_ops dom0?
Pasi has been doing a good job keeping
http://wiki.xensource.com/xenwiki/XenParavirtOps up to date.
Thanks,
J
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: pv_ops dom0 attempt
2009-09-19 0:27 ` Jeremy Fitzhardinge
@ 2009-09-20 12:22 ` Yu, Ke
0 siblings, 0 replies; 3+ messages in thread
From: Yu, Ke @ 2009-09-20 12:22 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Christopher S. Aker; +Cc: xen-devel >> xen devel
How many processors your platform have? We once observe an similar issue in a 64 processors platform. The issue is gone after changing the CONFIG_NR_CPUS from 8 to 256.
Best Regards
Ke
-----Original Message-----
From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
Sent: Saturday, September 19, 2009 8:27 AM
To: Christopher S. Aker
Cc: xen-devel >> xen devel; Pasi Kärkkäinen; Yu, Ke
Subject: Re: pv_ops dom0 attempt
On 09/18/09 13:03, Christopher S. Aker wrote:
> Decided to give pv_ops dom0 another go (from a few weeks ago). Does
> pv_ops dom0 require an unstable hypervisor? Here's what I get with a
> 64 bit 3.4.1 hypervisor and a dom0 kernel from a a recent clone of
> rebase/master:
>
> BUG: unable to handle kernel paging request at 82c64bbd
> IP: [<c14ad4cd>] acpi_processor_start+0x50d/0x762
> *pdpt = 00000009256e7007
> Oops: 0002 [#1] SMP
> last sysfs file:
> Modules linked in:
That's novel; I haven't seen that crash before. Could you do a "list
*0xc14ad4cd" to work out what source line it hit. What's your .config?
I wonder if this has to do with the external processor control stuff?
> Full boot log here: http://p.linode.com/2993
>
> What is the recommended recipe for pv_ops dom0?
Pasi has been doing a good job keeping
http://wiki.xensource.com/xenwiki/XenParavirtOps up to date.
Thanks,
J
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-20 12:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-18 20:03 pv_ops dom0 attempt Christopher S. Aker
2009-09-19 0:27 ` Jeremy Fitzhardinge
2009-09-20 12:22 ` Yu, Ke
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.