Keir Fraser
2010-May-04 12:00 UTC
[Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2010-May-05 09:50 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2010-May-06 14:13 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-06 14:26 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2010-May-06 16:13 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-06 16:34 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-May-06 18:50 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2010-May-06 19:13 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-May-06 20:17 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Zhang, Xiantao
2010-May-07 02:03 UTC
RE: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-07 07:10 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
M A Young
2010-May-07 18:33 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-May-07 23:11 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-08 08:05 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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
Boris Derzhavets
2010-May-08 11:00 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-May-08 15:14 UTC
[Xen-devel] Errors when loading 2.6.32.12 under Xen 4.0 on ASUS P5Q-E
[ 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Langsdorf, Mark
2010-May-12 17:50 UTC
RE: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-12 19:21 UTC
Re: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Langsdorf, Mark
2010-May-12 19:42 UTC
RE: [Xen-devel] Sixth (and final?) release candidate for Xen 3.4.3
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel