Sixth (and final?) release candidate for Xen 3.4.3

Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

Folks,

3.4.3-rc6 is now tagged in http://xenbits.xensource.com/xen-3.4-testing.hg

I hope that this will be the final RC before the 3.4.3 release. Please test!

 Thanks,
 Keir

Re: Sixth (and final?) release candidate for Xen 3.4.3

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 453 bytes --]

On Tue, 4 May 2010, Keir Fraser wrote:

> 3.4.3-rc6 is now tagged in http://xenbits.xensource.com/xen-3.4-testing.hg
>
> I hope that this will be the final RC before the 3.4.3 release. Please test!

Fedora 13 has compile problems similar to those that were in xen 4.0 rc
(and were fixed by changeset 21036)
http://xenbits.xensource.com/xen-4.0-testing.hg?rev/c1f272c3a441

The attached patch fixes the 3.4.3-rc6 compile problems for me.

 	Michael Young

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1048 bytes --]

--- a/tools/blktap/drivers/blktapctrl.c	Mon Mar 15 13:25:30 2010 +0000
+++ b/tools/blktap/drivers/blktapctrl.c	Mon Mar 15 17:08:29 2010 +0000
@@ -51,6 +51,7 @@
 #include <xs.h>
 #include <sys/time.h>
 #include <syslog.h>
+#include <sys/stat.h>
                                                                      
 #include "blktaplib.h"
 #include "blktapctrl.h"
--- a/tools/blktap/drivers/block-qcow2.c	Mon Mar 15 13:25:30 2010 +0000
+++ b/tools/blktap/drivers/block-qcow2.c	Mon Mar 15 17:08:29 2010 +0000
@@ -30,6 +30,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <sys/stat.h>
 
 #include "tapdisk.h"
 #include "tapaio.h"
--- a/tools/fs-back/Makefile	Mon Mar 15 13:25:30 2010 +0000
+++ b/tools/fs-back/Makefile	Mon Mar 15 17:08:29 2010 +0000
@@ -16,7 +16,7 @@ LIBS      := -L. -L.. -L../lib
 LIBS      := -L. -L.. -L../lib
 LIBS      += $(LDFLAGS_libxenctrl)
 LIBS      += $(LDFLAGS_libxenstore)
-LIBS      += -lrt 
+LIBS      += -lrt -lpthread
 
 OBJS	  := fs-xenbus.o fs-ops.o
 


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Sixth (and final?) release candidate for Xen 3.4.3

[M A Young]

On Tue, 4 May 2010, Keir Fraser wrote:

> Folks,
>
> 3.4.3-rc6 is now tagged in http://xenbits.xensource.com/xen-3.4-testing.hg
>
> I hope that this will be the final RC before the 3.4.3 release. Please test!

I have another issue, though I am not sure if it is a kernel issue or xen. 
On an i686 machine I get the early crash below with a pvops kernel under a 
xen 3.4.3-rc6 hypervisor. The same machine will boot with a xen 4.0.0 
hypervisor.

 	Michael Young

...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 124kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from f5c079fc:
(XEN)  L3[0x003] = 0000000018aaf001 00000aaf
(XEN)  L2[0x1ae] = 0000000000000000 ffffffff
(XEN) domain_crash_sync called from entry.S (ff1b339e)
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.4.3-rc6  x86_32p  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e019:[<c0a117da>]
(XEN) EFLAGS: 00000286   EM: 1   CONTEXT: pv guest
(XEN) eax: f5c079fc   ebx: 0001c7e9   ecx: 00000000   edx: 00000000
(XEN) esi: 00000000   edi: c0975ebc   ebp: c0975ecc   esp: c0975e88
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 18977000   cr2: f5c079fc
(XEN) ds: e021   es: e021   fs: 00d8   gs: 00e0   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c0975e88:
(XEN)    00000000 c0a117da 0001e019 00010086 0001c7e9 0001f740 00000000 0001c7ea
(XEN)    00000000 00000000 00000000 00000000 00007ff0 00101e7f c0ab5f60 00000003
(XEN)    00000000 c0975f04 c0a11a09 0001f740 00000000 00000006 000b0000 00000000
(XEN)    1c7e9000 00000000 00000006 c0a46e80 00000000 c0ab5f20 c0ab6960 c0975f18
(XEN)    c0a14e74 00000000 c0ab4f7c c0ab4e84 c0975f98 c0a13477 c0ac0e38 c0442d9a
(XEN)    00000000 00000000 00000000 00000035 00000000 000000bc 00000000 00000000
(XEN)    00000000 c09d7bf0 c0975fb8 c09b26bc 46db368e c09baca4 00000002 c09baca4
(XEN)    00000002 00000000 00000000 c09b26bc 46db368e 00000000 00000000 c09b26bc
(XEN)    46db368e 00000000 00000000 c09b26bc c0975fc0 c0a0e670 c08bcd87 c07b4010
(XEN)    9df85c6c 000000c2 46db368e eca287b5 c0a0e074 00cb2000 c0975fd0 c0a0e0af
(XEN)    00cb2000 c0a46e80 c0975ffc c0a113db 00000001 c04090a9 1fc99375 80000400
(XEN)    00010809 00000f27 00000000 c2672000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

On 06/05/2010 15:13, "M A Young" <m.a.young@durham.ac.uk> wrote:

> I have another issue, though I am not sure if it is a kernel issue or xen.
> On an i686 machine I get the early crash below with a pvops kernel under a
> xen 3.4.3-rc6 hypervisor. The same machine will boot with a xen 4.0.0
> hypervisor.

Do you have this issue with 3.4.2?

 -- Keir

Re: Sixth (and final?) release candidate for Xen 3.4.3

[M A Young]

On Thu, 6 May 2010, Keir Fraser wrote:

> On 06/05/2010 15:13, "M A Young" <m.a.young@durham.ac.uk> wrote:
>
>> I have another issue, though I am not sure if it is a kernel issue or xen.
>> On an i686 machine I get the early crash below with a pvops kernel under a
>> xen 3.4.3-rc6 hypervisor. The same machine will boot with a xen 4.0.0
>> hypervisor.
>
> Do you have this issue with 3.4.2?

No, it boots with 3.4.2 which I actually a bit surprised about as I didn't 
think 3.4.2 was compatible with that kernel though this might explain why 
the network doesn't work for 3.4.2.

 	Michael Young

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

On 06/05/2010 17:13, "M A Young" <m.a.young@durham.ac.uk> wrote:

>> Do you have this issue with 3.4.2?
> 
> No, it boots with 3.4.2 which I actually a bit surprised about as I didn't
> think 3.4.2 was compatible with that kernel though this might explain why
> the network doesn't work for 3.4.2.

Hm, there were changes to 3.4.3 to make it work better with pv_ops dom0
kernels. I'm thinking things like xen-3.4-testing:19862 and 19863. I suggest
you post more details and you should get help from pv_ops people (I cc'ed a
couple of them :-). They may be able to tell you straight off whether your
pv_ops kernel is too old/new/weird/whatever, for example.

 -- Keir

RE: Sixth (and final?) release candidate for Xen 3.4.3

[Zhang, Xiantao]

Keir Fraser wrote:
> On 06/05/2010 17:13, "M A Young" <m.a.young@durham.ac.uk> wrote:
> 
>>> Do you have this issue with 3.4.2?
>> 
>> No, it boots with 3.4.2 which I actually a bit surprised about as I
>> didn't think 3.4.2 was compatible with that kernel though this might
>> explain why the network doesn't work for 3.4.2.
> 
> Hm, there were changes to 3.4.3 to make it work better with pv_ops
> dom0 kernels. I'm thinking things like xen-3.4-testing:19862 and
> 19863. I suggest you post more details and you should get help from
> pv_ops people (I cc'ed a couple of them :-). They may be able to tell
> you straight off whether your pv_ops kernel is too
> old/new/weird/whatever, for example. 

As I know, you have to backport extra Csets like 28089, 21092, and 21161 from xen-unstable.hg to make it work well with latest pv_ops kernel except the Csets Keir had indicated. 
Xiantao

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

On 07/05/2010 03:03, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

>> Hm, there were changes to 3.4.3 to make it work better with pv_ops
>> dom0 kernels. I'm thinking things like xen-3.4-testing:19862 and
>> 19863. I suggest you post more details and you should get help from
>> pv_ops people (I cc'ed a couple of them :-). They may be able to tell
>> you straight off whether your pv_ops kernel is too
>> old/new/weird/whatever, for example.
> 
> As I know, you have to backport extra Csets like 28089, 21092, and 21161 from
> xen-unstable.hg to make it work well with latest pv_ops kernel except the
> Csets Keir had indicated.

Doesn't sound like 3.4.3 is going to support pv_ops then.

 -- Keir

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Jeremy Fitzhardinge]

On 05/07/2010 12:10 AM, Keir Fraser wrote:
> On 07/05/2010 03:03, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:
>
>   
>>> Hm, there were changes to 3.4.3 to make it work better with pv_ops
>>> dom0 kernels. I'm thinking things like xen-3.4-testing:19862 and
>>> 19863. I suggest you post more details and you should get help from
>>> pv_ops people (I cc'ed a couple of them :-). They may be able to tell
>>> you straight off whether your pv_ops kernel is too
>>> old/new/weird/whatever, for example.
>>>       
>> As I know, you have to backport extra Csets like 28089, 21092, and 21161 from
>> xen-unstable.hg to make it work well with latest pv_ops kernel except the
>> Csets Keir had indicated.
>>     
> Doesn't sound like 3.4.3 is going to support pv_ops then.
>   

Florian and M A Young have reported success with 3.4.3-rc, so it isn't
completely non-functional.  How essential are those changes?   28089
doesn't appear in my tree ("abort: unknown revision '28089'"), but 21092
("Allow all unused GSI to be configured via IO-APIC by new pv_ops dom0")
and 21161 ("Make c/s 21089 work again with c/s 21092") both look pertient.

    J

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

On 08/05/2010 00:11, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

>>> As I know, you have to backport extra Csets like 28089, 21092, and 21161
>>> from
>>> xen-unstable.hg to make it work well with latest pv_ops kernel except the
>>> Csets Keir had indicated.
>>>     
>> Doesn't sound like 3.4.3 is going to support pv_ops then.
>>   
> 
> Florian and M A Young have reported success with 3.4.3-rc, so it isn't
> completely non-functional.  How essential are those changes?   28089
> doesn't appear in my tree ("abort: unknown revision '28089'"), but 21092
> ("Allow all unused GSI to be configured via IO-APIC by new pv_ops dom0")
> and 21161 ("Make c/s 21089 work again with c/s 21092") both look pertient.

I doubt anyone is running pv_ops dom0 in serious production uses yet. So I'm
not sure backporting this sort of stuff to our very stable branch is really
necessary. Anyone running pv_ops dom0 is likely not scared of Xen 4.0.

 -- Keir

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1859 bytes --]

I believe 3.4.3 stable release would make sense only supporting  2.6.32.12 pvops.
Otherwise, you already have 3.4.2. Maybe you care about xenified aka Suse kernels
It would be different concern.

Boris.

--- On Sat, 5/8/10, Keir Fraser <keir.fraser@eu.citrix.com> wrote:

From: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Florian Wagner" <f_wagner@syscomp.de>, "Zhang, Xiantao" <xiantao.zhang@intel.com>, "M A Young" <m.a.young@durham.ac.uk>
Date: Saturday, May 8, 2010, 4:05 AM

On 08/05/2010 00:11, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

>>> As I know, you have to backport extra Csets like 28089, 21092, and 21161
>>> from
>>> xen-unstable.hg to make it work well with latest pv_ops kernel except the
>>> Csets Keir had indicated.
>>>     
>> Doesn't sound like 3.4.3 is going to support pv_ops then.
>>   
> 
> Florian and M A Young have reported success with 3.4.3-rc, so it isn't
> completely non-functional.  How essential are those changes?   28089
> doesn't appear in my tree ("abort: unknown revision '28089'"), but 21092
> ("Allow all unused GSI to be configured via IO-APIC by new pv_ops dom0")
> and 21161 ("Make c/s 21089 work again with c/s 21092") both look pertient.

I doubt anyone is running pv_ops dom0 in serious production uses yet. So I'm
not sure backporting this sort of stuff to our very stable branch is really
necessary. Anyone running pv_ops dom0 is likely not scared of Xen 4.0.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2656 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Errors when loading 2.6.32.12 under Xen 4.0 on ASUS P5Q-E

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 3211 bytes --]

[   12.410644] BUG: unable to handle kernel paging request at ffff8801e3b64010
[   12.410723] IP: [<ffffffff8100f1c8>] xen_set_pmd+0x38/0xb0
[   12.410778] PGD 1002067 PUD 106b7067 PMD 107d5067 PTE 80100001e3b64065
[   12.410894] Oops: 0003 [#1] SMP 
[   12.410964] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/host6/target6:0:0/6:0:0:0/vendor
[   12.411000] CPU 0 
[   12.411048] Modules linked in: usbhid hid pata_marvell ohci1394 skge ieee1394 r8169 mii floppy ahci sky2
[   12.411364] Pid: 721, comm: dmsetup_env Not tainted 2.6.32.12 #4 P5Q-E
[   12.411394] RIP: e030:[<ffffffff8100f1c8>]  [<ffffffff8100f1c8>] xen_set_pmd+0x38/0xb0
[   12.411453] RSP: e02b:ffff8801e3b7ba88  EFLAGS: 00010246
[   12.411483] RAX: 0000000000000000 RBX: ffff8801e3b64010 RCX: ffff880000000000
[   12.411516] RDX: ffffea0000000000 RSI: 0000000000000000 RDI: ffff8801e3b64010
[   12.411546] RBP: ffff8801e3b7ba98 R08: 0000000000f0d000 R09: 0000000000000000
[   12.411583] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[   12.411614] R13: ffff8801e3b64010 R14: 000000000061c000 R15: ffff880016c7a9e0
[   12.411650] FS:  00007fb766f52700(0000) GS:ffff880016c6c000(0000) knlGS:0000000000000000
[   12.411687] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[   12.411717] CR2: ffff8801e3b64010 CR3: 00000001e3308000 CR4: 0000000000002660
[   12.411747] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   12.411778] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   12.411808] Process dmsetup_env (pid: 721, threadinfo ffff8801e3b7a000, task ffff8801e27063c0)
[   12.411841] Stack:
[   12.411868]  0000000000600000 00000001e7f08067 ffff8801e3b7bb68 ffffffff8110b12c
[   12.411964] <0> ffff8801e3b7bab8 ffff8801e41e8690 0000000000000001 ffffffffffffffff
[   12.412108] <0> ffffffffffffffff 0000000000000000 0000000000000000 000000000061bfff
[   12.412282] Call Trace:
[   12.412314]  [<ffffffff8110b12c>] free_pgd_range+0x25c/0x4b0
[   12.412346]  [<ffffffff8110b44e>] free_pgtables+0xce/0x120
[   12.412378]  [<ffffffff81110f66>] exit_mmap+0x106/0x1e0
[   12.412410]  [<ffffffff810604e2>] mmput+0x42/0x100
[   12.412442]  [<ffffffff8113f149>] flush_old_exec+0x3f9/0x5a0
[   12.412475]  [<ffffffff8118112f>] load_elf_binary+0x38f/0x1d40
[   12.412506]  [<ffffffff8110a766>] ? follow_page+0x2d6/0x350
[   12.412539]  [<ffffffff8110ef47>] ? __get_user_pages+0x197/0x4b0
[   12.412570]  [<ffffffff8113e67c>] ? get_arg_page+0x5c/0xc0
[   12.412601]  [<ffffffff8114002b>] search_binary_handler+0x10b/0x330
[   12.412634]  [<ffffffff81140673>] do_execve+0x323/0x410
[   12.412666]  [<ffffffff810125aa>] sys_execve+0x4a/0x80
[   12.412697]  [<ffffffff8101450a>] stub_execve+0x6a/0xc0
[   12.412726] Code: 89 64 24 08 0f 1f 44 00 00 80 3d 1f 90 94 00 00 48 89 fb 49 89 f4 75 48 48 89 df 83 05 59 8f 94 00 01 e8 7c e2 ff ff 84 c0 75 18 <4c> 89 23 48 8b 1c 24 4c 8b 64 24 08 c9 c3 66 2e 0f 1f 84 00 00 
[   12.414246] RIP  [<ffffffff8100f1c8>] xen_set_pmd+0x38/0xb0
[   12.414299]  RSP <ffff8801e3b7ba88>
[   12.414329] CR2: ffff8801e3b64010
[   12.414360] ---[ end trace 74ad9aef35883a7a ]---

Boris



      

[-- Attachment #1.2: Type: text/html, Size: 4104 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Sixth (and final?) release candidate for Xen 3.4.3

[Langsdorf, Mark]

Keir -

AMD is seeing an issue with Xen-3.4.3-rc7-pre and
Xen-4.0-rc1 that makes me think there's an unknown
race condition lurking in on_selected_cpus().

Sometimes, on the new 6-core processors, the powernow.c
driver call:

    on_selected_cpus(&cmd.mask, transition_pstate, &cmd, 0);

results in a corrupted cmd structure in transition_pstate().
I wrote some test code that checks that cmd->val is the
desired value before the on_selected_cpus() call, and it
is, but sometimes (very irregularly), cmd->val is grossly
out of range inside transition_pstate().

We're mostly seeing this on our new 6 core systems, but
they're getting the most attention in our testing right 
now.

Any help in debugging why this is occuring would be 
appreciated.  I'm requesting that Xen-3.4.3 be held until
this is resolved.

--Mark Langsdorf
Operating System Research Center
AMD

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Keir Fraser]

On 12/05/2010 18:50, "Langsdorf, Mark" <mark.langsdorf@amd.com> wrote:

> Sometimes, on the new 6-core processors, the powernow.c
> driver call:
> 
>     on_selected_cpus(&cmd.mask, transition_pstate, &cmd, 0);

Since you specify '0' for the final 'wait' parameter of on_selected_cpus(),
the call can return before transition_pstate() has finished executing on all
the requested CPUs. Hence the calling function (powernow_cpufreq_target) can
exit early, and 'cmd' becomes invalid as it is allocated in the function's
stack frame.

The fix is simply to specify '1' for the final parameter of
on_selected_cpus(). I will apply the fix to all trees and also have a quick
audit that all other callers who specify '0' really mean to.

 -- Keir

RE: Sixth (and final?) release candidate for Xen 3.4.3

[Langsdorf, Mark]

> > Sometimes, on the new 6-core processors, the powernow.c
> > driver call:
> > 
> >     on_selected_cpus(&cmd.mask, transition_pstate, &cmd, 0);
> 
> Since you specify '0' for the final 'wait' parameter of 
> on_selected_cpus(),
> the call can return before transition_pstate() has finished 
> executing on all
> the requested CPUs.

Thanks!

I copied that code from the Intel cpufreq driver, and I
doubt that's what they intended either.

--Mark Langsdorf
Operating System Research Center
AMD

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Jeremy Fitzhardinge]

On 05/06/2010 07:13 AM, M A Young wrote:
> On Tue, 4 May 2010, Keir Fraser wrote:
>
>> Folks,
>>
>> 3.4.3-rc6 is now tagged in
>> http://xenbits.xensource.com/xen-3.4-testing.hg
>>
>> I hope that this will be the final RC before the 3.4.3 release.
>> Please test!
>
> I have another issue, though I am not sure if it is a kernel issue or
> xen. On an i686 machine I get the early crash below with a pvops
> kernel under a xen 3.4.3-rc6 hypervisor. The same machine will boot
> with a xen 4.0.0 hypervisor.

What kernel version is it?  2.6.31.x should work with a pre-3.4.3 Xen
(and post, of course).  I wouldn't expect 2.6.32.x kernel to work *at
all* on a pre-3.4.3 Xen (well, you'd get some boot messages, but no
device interrupts would work).

    J

>
>     Michael Young
>
> ...
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 124kB init memory.
> mapping kernel into physical memory
> Xen: setup ISA identity maps
> about to get started...
> (XEN) d0:v0: unhandled page fault (ec=0000)
> (XEN) Pagetable walk from f5c079fc:
> (XEN)  L3[0x003] = 0000000018aaf001 00000aaf
> (XEN)  L2[0x1ae] = 0000000000000000 ffffffff
> (XEN) domain_crash_sync called from entry.S (ff1b339e)
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.4.3-rc6  x86_32p  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) EIP:    e019:[<c0a117da>]

Can you map this to a function?

Thanks,
    J

> (XEN) EFLAGS: 00000286   EM: 1   CONTEXT: pv guest
> (XEN) eax: f5c079fc   ebx: 0001c7e9   ecx: 00000000   edx: 00000000
> (XEN) esi: 00000000   edi: c0975ebc   ebp: c0975ecc   esp: c0975e88
> (XEN) cr0: 8005003b   cr4: 000006f0   cr3: 18977000   cr2: f5c079fc
> (XEN) ds: e021   es: e021   fs: 00d8   gs: 00e0   ss: e021   cs: e019
> (XEN) Guest stack trace from esp=c0975e88:
> (XEN)    00000000 c0a117da 0001e019 00010086 0001c7e9 0001f740
> 00000000 0001c7ea
> (XEN)    00000000 00000000 00000000 00000000 00007ff0 00101e7f
> c0ab5f60 00000003
> (XEN)    00000000 c0975f04 c0a11a09 0001f740 00000000 00000006
> 000b0000 00000000
> (XEN)    1c7e9000 00000000 00000006 c0a46e80 00000000 c0ab5f20
> c0ab6960 c0975f18
> (XEN)    c0a14e74 00000000 c0ab4f7c c0ab4e84 c0975f98 c0a13477
> c0ac0e38 c0442d9a
> (XEN)    00000000 00000000 00000000 00000035 00000000 000000bc
> 00000000 00000000
> (XEN)    00000000 c09d7bf0 c0975fb8 c09b26bc 46db368e c09baca4
> 00000002 c09baca4
> (XEN)    00000002 00000000 00000000 c09b26bc 46db368e 00000000
> 00000000 c09b26bc
> (XEN)    46db368e 00000000 00000000 c09b26bc c0975fc0 c0a0e670
> c08bcd87 c07b4010
> (XEN)    9df85c6c 000000c2 46db368e eca287b5 c0a0e074 00cb2000
> c0975fd0 c0a0e0af
> (XEN)    00cb2000 c0a46e80 c0975ffc c0a113db 00000001 c04090a9
> 1fc99375 80000400
> (XEN)    00010809 00000f27 00000000 c2672000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000
> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Sixth (and final?) release candidate for Xen 3.4.3

[M A Young]

On Thu, 6 May 2010, Jeremy Fitzhardinge wrote:

> On 05/06/2010 07:13 AM, M A Young wrote:
>> On Tue, 4 May 2010, Keir Fraser wrote:
>>
>>> Folks,
>>>
>>> 3.4.3-rc6 is now tagged in
>>> http://xenbits.xensource.com/xen-3.4-testing.hg
>>>
>>> I hope that this will be the final RC before the 3.4.3 release.
>>> Please test!
>>
>> I have another issue, though I am not sure if it is a kernel issue or
>> xen. On an i686 machine I get the early crash below with a pvops
>> kernel under a xen 3.4.3-rc6 hypervisor. The same machine will boot
>> with a xen 4.0.0 hypervisor.
>
> What kernel version is it?  2.6.31.x should work with a pre-3.4.3 Xen
> (and post, of course).  I wouldn't expect 2.6.32.x kernel to work *at
> all* on a pre-3.4.3 Xen (well, you'd get some boot messages, but no
> device interrupts would work).

It was from stable-2.6.32.x circa 10th April. However I have lost the 
debuginfo rpm for that kernel, so I will try again with a more up-to-date 
kernel tomorrow.

 	Michael Young

Re: Sixth (and final?) release candidate for Xen 3.4.3

[Jeremy Fitzhardinge]

On 05/06/2010 12:13 PM, M A Young wrote:
> It was from stable-2.6.32.x circa 10th April. However I have lost the
> debuginfo rpm for that kernel, so I will try again with a more
> up-to-date kernel tomorrow.

Thanks.  No idea how that kernel was doing anything useful on a 3.4.2
Xen though, unless you'd also patched it?

    J

Re: Sixth (and final?) release candidate for Xen 3.4.3

[M A Young]

On Thu, 6 May 2010, Jeremy Fitzhardinge wrote:

> On 05/06/2010 12:13 PM, M A Young wrote:
>> It was from stable-2.6.32.x circa 10th April. However I have lost the
>> debuginfo rpm for that kernel, so I will try again with a more
>> up-to-date kernel tomorrow.
>
> Thanks.  No idea how that kernel was doing anything useful on a 3.4.2
> Xen though, unless you'd also patched it?

A new build from stable-2.6.32.x does boot on 3.4.3-rc6, so presumably 
whatever was the problem is fixed in the latest kernel patches.
It does boot on 3.4.2 (the standard Fedora 13 package) though I didn't try 
anything other than booting it.

 	Michael Young