Nathan March
2011-Jan-27 20:21 UTC
[Xen-devel] Live migration bug introduced in 2.6.32.16?
Hi All,
It looks like a live migration bug may have been introduced in 2.6.32.16...
I''ve been experiencing issues where upon live migration, the domU
simply
hangs once it gets resumed on the target dom0. I''ve been unable to get
any crash information out of the domU, nothing comes up in xm dmesg.
There could be a kernel panic happening but since I can''t connect to
the
console during the migration I haven''t been able to get anything
useful.
Comparing a successful migration to a failed one in the xend.log and
xen-debug.log, nothing stands out as being different.
Testing a wide variety of VM''s to see why some worked and some
didn''t,
I''ve narrowed it down to the domU kernel version and down to 2.6.32.16
specifically by trying these versions:
2.6.32.8 good
2.6.32.15 good
2.6.32.16 bad
2.6.32.17 bad
2.6.32.20 bad
2.6.32.24 bad
2.6.32.28 bad
2.6.37 bad
All are the stock kernel off kernel.org.
Note that this isn''t consistent at all, I''ve got 6
dom0''s and this only
happens when migrating certain directions between certain dom0''s:
xen1->xen2 crash
xen1->xen5 crash
xen1->xen6 crash
xen2->xen5 crash
xen2->xen1 works
xen3->xen1 works
xen5->xen2 works
xen5->xen6 works
xen6->xen1 works
xen6->xen5 works
Previously, xen6->5 worked but xen5->6 didn''t work. After a few
reboots
(of the dom0) however the problem between them resolved itself and now I
can go xen5->6 and back all day on 2.6.32.16 without issues. If i then
migrate it to xen1 it''s fine, but back to xen5 and it locks up on
resume.
All 6 xen dom0''s are identical:
xen5 ~ # xm info
host : xen5
release : 2.6.31.13
version : #11 SMP Wed Jan 26 10:55:28 PST 2011
machine : x86_64
nr_cpus : 12
nr_nodes : 2
cores_per_socket : 6
threads_per_core : 1
cpu_mhz : 2266
hw_caps :
bfebfbff:2c100800:00000000:00001f40:009ee3fd:00000000:00000001:00000000
virt_caps : hvm hvm_directio
total_memory : 40950
free_memory : 38380
node_to_cpu : node0:0-5
node1:6-11
node_to_memory : node0:23388
node1:14991
node_to_dma32_mem : node0:2994
node1:0
max_node_id : 1
xen_major : 4
xen_minor : 0
xen_extra : .1-rc6-pre
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
xen_commandline : console=com1,com2,vga com1=115200,8n1
com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true
cc_compiler : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
cc_compile_by : root
cc_compile_domain :
cc_compile_date : Tue Jan 25 17:05:03 PST 2011
xend_config_format : 4
I''ve tried updating to a newer dom0 release but ran into linking issues
due to as-needed so I haven''t managed to get them up yet.
Looking at the changelog for 2.6.32.16
(http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.16) there
were two xen patches made, both involving resuming.
Diffs for the two patches:
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commitdiff;h=0f58db21025d979e38db691861985ebc931551b1
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commitdiff;h=b6d1fd29840e29d1a87d0ab15ee1ccc90ea15ec4
I''ve tried reversing them together and 1 at a time, yet the problem
still happens. I then took 2.6.32.15 and applied those patches and it''s
completely stable. So whatever is causing this was apparently not a
xen-related patch?
Anyone have any ideas on what might be going on here or how I can debug
it further? I''m completely stumped at this point, don''t want
to just try
applying every patch in 2.6.32.16 to see which one is doing it.
Compiling + testing all these kernels is time consuming =)
Thanks,
Nathan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jan-27 20:36 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On Thu, Jan 27, 2011 at 12:21:14PM -0800, Nathan March wrote:> Hi All, > > It looks like a live migration bug may have been introduced in 2.6.32.16...Whoa.. nice job figuring out what is wrong. One question: did you try to use the git branch from Jeremy''s tree as a DomU?> Anyone have any ideas on what might be going on here or how I can > debug it further? I''m completely stumped at this point, don''t want > to just try applying every patch in 2.6.32.16 to see which one is > doing it. Compiling + testing all these kernels is time consuming =)git bisect is a great tool for this. You can fetch Linus''s tree and the tools for this - takes only about a day to find the culprit. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nathan March
2011-Jan-27 20:42 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On 1/27/2011 12:36 PM, Konrad Rzeszutek Wilk wrote:> Whoa.. nice job figuring out what is wrong. One question: did you > try to use the git branch from Jeremy''s tree as a DomU? >No, should I? I''ve been under the impression that domU support in mainline has been pretty solid for a while now. I''ll give it a try if you think it''s worth it.> git bisect is a great tool for this. You can fetch Linus''s tree and > the tools for this - takes only about a day to find the culprit. >Haven''t worked with git much yet but I''ll take a look! - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jan-27 20:57 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On Thu, 2011-01-27 at 20:42 +0000, Nathan March wrote:> On 1/27/2011 12:36 PM, Konrad Rzeszutek Wilk wrote: > > Whoa.. nice job figuring out what is wrong. One question: did you > > try to use the git branch from Jeremy''s tree as a DomU? > > > > No, should I? I''ve been under the impression that domU support in > mainline has been pretty solid for a while now. I''ll give it a try if > you think it''s worth it.I think it''s worth a shot since it would indicate whether or not we have simply missed getting a patch into the upstream stable kernel or if we have a totally new issue. I fixed a bunch of migration issues which were introduced in the 2.6.32.16 time frame around about the 2.6.32.18-19 time frame (IIRC my memory''s a bit fuzzy). I wasn''t aware of any further subsequent breakage though. Are the guests 32 or 64 bit? How about the hypervisor and dom0 kernel? What is your kernel''s .config? If you edit /etc/sysconfig/{xencommons,xend} (whichever one you have) then you can set XENCONSOLED_TRACE=guest which will write guest consoles to /var/log/xen/domain. Also setting "on_crash=preserve" in your guest configuration will hopefully cause them to stick around long enough to see what was on the console.> > git bisect is a great tool for this. You can fetch Linus''s tree and > > the tools for this - takes only about a day to find the culprit. > > > Haven''t worked with git much yet but I''ll take a look!Thanks, that would be worthwhile. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nathan March
2011-Jan-27 22:54 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On 1/27/2011 12:57 PM, Ian Campbell wrote:> > Are the guests 32 or 64 bit? How about the hypervisor and dom0 kernel? > What is your kernel''s .config?All 64bit. Config is attached.> If you edit /etc/sysconfig/{xencommons,xend} (whichever one you have) > then you can set XENCONSOLED_TRACE=guest which will write guest consoles > to /var/log/xen/domain. Also setting "on_crash=preserve" in your guest > configuration will hopefully cause them to stick around long enough to > see what was on the console. >Will try that. The domUs don''t actually fully crash, they just lock up. The VM keeps running until I destroy it. Trying to attach to the console when it''s in this state results in xenconsole hanging on an select against fd 3/4/5 (socket, pipe + pipe) I''ll try all the things suggested and let you guys know what I find. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jan-27 23:27 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On Thu, Jan 27, 2011 at 02:54:54PM -0800, Nathan March wrote:> On 1/27/2011 12:57 PM, Ian Campbell wrote: > > > >Are the guests 32 or 64 bit? How about the hypervisor and dom0 kernel? > >What is your kernel''s .config? > All 64bit. Config is attached. > > >If you edit /etc/sysconfig/{xencommons,xend} (whichever one you have) > >then you can set XENCONSOLED_TRACE=guest which will write guest consoles > >to /var/log/xen/domain. Also setting "on_crash=preserve" in your guest > >configuration will hopefully cause them to stick around long enough to > >see what was on the console. > > > Will try that. The domUs don''t actually fully crash, they just lock > up. The VM keeps running until I destroy it. Trying to attach to the > console when it''s in this state results in xenconsole hanging on an > select against fd 3/4/5 (socket, pipe + pipe)You could run ''xenctx'' and get a stack trace of what the guest is doing. That could narrow it down.> > I''ll try all the things suggested and let you guys know what I find.OK. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nathan March
2011-Jan-28 00:51 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On 1/27/2011 12:36 PM, Konrad Rzeszutek Wilk wrote:> Whoa.. nice job figuring out what is wrong. One question: did you > try to use the git branch from Jeremy''s tree as a DomU?Unfortunately this doesn''t seem to be possible, whenever I try to start a domU with the latest from his git it crashes immediately. I''ve tried everything I can think of, I suspect it''s due to my outdated hypervisor (4.0.1rc6) but it''s not that far behind. Tried with and without grub/libvirtd, same effect. Config used is the same as the one I attached earlier, leaving any new options disabled. (XEN) d74:v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from ffffffff817128c8: (XEN) L4[0x1ff] = 0000000a27fc9067 0000000000001003 (XEN) L3[0x1fe] = 0000000a27fc5067 0000000000001007 (XEN) L2[0x00b] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S (XEN) Domain 74 (vcpu#0) crashed on cpu#11: (XEN) ----[ Xen-4.0.1-rc6-pre x86_64 debug=n Not tainted ]---- (XEN) CPU: 11 (XEN) RIP: e033:[<ffffffff8100ba99>] (XEN) RFLAGS: 0000000000000202 EM: 1 CONTEXT: pv guest (XEN) rax: ffffffff81712000 rbx: 0000000001d19067 rcx: 000000000000000e (XEN) rdx: 0000000000000000 rsi: 0010000a272b3065 rdi: 0000000000000119 (XEN) rbp: ffffffff814a1d60 rsp: ffffffff814a1d20 r8: 00000000000008c8 (XEN) r9: 00003ffffffff000 r10: ffff880000000000 r11: 0000000000000010 (XEN) r12: ffff880001d19000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 0000000a27fcb000 cr2: ffffffff817128c8 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff814a1d20: (XEN) 000000000000000e 0000000000000010 0000000000000000 ffffffff8100ba99 (XEN) 000000010000e030 0000000000010002 ffffffff814a1d60 000000000000e02b (XEN) ffffffff814a1d78 ffffffff8100bb95 ffffffff81001ea0 ffffffff814a1d88 (XEN) ffffffff8100bc41 ffffffff814a1dd8 ffffffff8100b99a 0000000000000010 (XEN) ffff880000000000 00003ffffffff000 00000000000008c8 0000000001d19067 (XEN) 0010000a272b3065 0000000000000000 0000000000000001 ffffffff814a1e08 (XEN) ffffffff8154f258 0000000000000001 0000000000000000 ffffea0000000000 (XEN) 0000000000000000 ffffffff814a1e68 ffffffff8154dcb2 ffffffff814a1e58 (XEN) ffffffff8153a15d ffffea00001bffff 0000000001000000 ffffea00001c0000 (XEN) ffffea0000000000 0000000000000000 0000000000000000 ffff8800015e6000 (XEN) 0000000000000000 ffffffff814a1e88 ffffffff8154f0d5 ffffffff814a1f80 (XEN) 0000000000000000 ffffffff814a1ed8 ffffffff8153ba63 0000000000000001 (XEN) ffff880001918000 ffff880001d18000 ffffffff814a1ee8 ffffffffffffffff (XEN) ffffffff814a1f80 0000000000000000 0000000000000000 ffffffff814a1f18 (XEN) ffffffff81536770 0000000000001000 0000000000100000 0000000000040800 (XEN) 0000000000000000 ffffffff814a1f18 00000000015e6000 ffffffff814a1f68 (XEN) ffffffff8152b339 ffffffff814a1f38 ffffffff81375c71 ffffffff814a1f58 (XEN) ffffffff81055316 00000000015d9e48 0000000000000000 ffffffffffffffff (XEN) ffffffff8154fd40 ffffffff814a1fa8 ffffffff81527998 ffffffff814a1fa8 (XEN) ffffffff81553360 00000000015d9e48 0000000000000000 0000000000000000> You could run ''xenctx'' and get a stack trace of what the guest is doing. > That could narrow it down.Hopefully this means something to you =) xen5 ~ # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1017 1 r----- 76.5 nathanxen3 6 1024 2 -b---- 0.0 xen5 ~ # /usr/lib64/xen/bin/xenctx --stack-trace -a 6 0 rip: ffffffff810093aa flags: 00001246 i z p rsp: ffffffff81497f00 rax: 0000000000000000 rcx: ffffffff810093aa rdx: 0000000000000246 rbx: ffffffff81496000 rsi: 0000000000000000 rdi: 0000000000000001 rbp: ffffffff81497f18 r8: 0000000000000000 r9: ffffffff81497e18 r10: 000000000000000c r11: 0000000000000246 r12: ffffffff81505350 r13: ffffffff81543b10 r14: ffffffff81546730 r15: 0000000000000000 cs: e033 ss: e02b ds: 0000 es: 0000 fs: 0000 @ 00007f039010b700 gs: 0000 @ ffff88000181f000/0000000000000000 cr0: 8005003b cr2: 7fff4e149ff0 cr3: 8ebcd5000 cr4: 00002660 dr0: 00000000 dr1: 00000000 dr2: 00000000 dr3: 00000000 dr6: ffff0ff0 dr7: 00000400 Code (instr addr ffffffff810093aa) cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc Stack: ffff88003f8a5da0 0000000000000000 ffffffff8100d53c ffffffff81497f38 ffffffff8100b3ef ffffffff81497f38 ffffffff81497fd8 ffffffff81497f58 ffffffff8100f24e 0000000000000000 ffffffffffffffff ffffffff81497f68 ffffffff81353e9d ffffffff81497fa8 ffffffff8151cbe4 ffffffff81497fa8 Stack Trace: * [<ffffffff810093aa>] <-- ffff88003f8a5da0 0000000000000000 [<ffffffff8100d53c>] [<ffffffff81497f38>] [<ffffffff8100b3ef>] [<ffffffff81497f38>] [<ffffffff81497fd8>] [<ffffffff81497f58>] [<ffffffff8100f24e>] 0000000000000000 [<ffffffffffffffff>] [<ffffffff81497f68>] [<ffffffff81353e9d>] [<ffffffff81497fa8>] [<ffffffff8151cbe4>] [<ffffffff81497fa8>] [<ffffffff81546730>] 00000000015dd548 0000000000000000 0000000000000000 0000000000000000 [<ffffffff81497fc8>] [<ffffffff8151c295>] [<ffffffff81515590>] [<ffffffff81801000>] [<ffffffff81497ff8>] [<ffffffff8151deff>] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 xen5 ~ # /usr/lib64/xen/bin/xenctx --stack-trace -a 6 1 rip: ffffffff810093aa flags: 00001246 i z p rsp: ffff88003f851ee8 rax: 0000000000000000 rcx: ffffffff810093aa rdx: 0000002b02eb8fe8 rbx: ffff88003f850000 rsi: 0000000000000000 rdi: 0000000000000001 rbp: ffff88003f851f00 r8: 0000000000000000 r9: ffff88003f851e00 r10: 000000000000000c r11: 0000000000000246 r12: ffffffff81505350 r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000 cs: e033 ss: e02b ds: 002b es: 002b fs: 0000 @ 00002b62ff2fcb20 gs: 0000 @ ffff880001839000/0000000000000000 cr0: 8005003b cr2: 7f302f14ce10 cr3: 8ebc46000 cr4: 00002660 dr0: 00000000 dr1: 00000000 dr2: 00000000 dr3: 00000000 dr6: ffff0ff0 dr7: 00000400 Code (instr addr ffffffff810093aa) cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc Stack: ffff88003e169da0 0000000000000000 ffffffff8100d53c ffff88003f851f20 ffffffff8100b3ef ffff88003f851f20 ffff88003f851fd8 ffff88003f851f40 ffffffff8100f24e 0000000000000000 0000000000000000 ffff88003f851f50 ffffffff81365b59 0000000000000000 0000000000000000 0000000000000000 Stack Trace: * [<ffffffff810093aa>] <-- ffff88003e169da0 0000000000000000 [<ffffffff8100d53c>] ffff88003f851f20 [<ffffffff8100b3ef>] ffff88003f851f20 ffff88003f851fd8 ffff88003f851f40 [<ffffffff8100f24e>] 0000000000000000 0000000000000000 ffff88003f851f50 [<ffffffff81365b59>] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Philipp Hahn
2011-Jan-28 06:47 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
Hello, Am Donnerstag 27 Januar 2011 21:21:14 schrieb Nathan March:> It looks like a live migration bug may have been introduced in 2.6.32.16......> Note that this isn''t consistent at all, I''ve got 6 dom0''s and this only > happens when migrating certain directions between certain dom0''s:Sounds like a problem very similar to mine. Please check if you have the pvclock-going-backwards-problem: <http://lists.xensource.com/archives/html/xen-users/2011-01/msg00375.html> Sincerely Philipp -- Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jan-28 08:44 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
(Please don''t drop CC''s when posting to xen-devel) On Fri, 2011-01-28 at 06:47 +0000, Philipp Hahn wrote:> Hello, > > Am Donnerstag 27 Januar 2011 21:21:14 schrieb Nathan March: > > It looks like a live migration bug may have been introduced in 2.6.32.16... > ... > > Note that this isn''t consistent at all, I''ve got 6 dom0''s and this only > > happens when migrating certain directions between certain dom0''s: > > Sounds like a problem very similar to mine. Please check if you have the > pvclock-going-backwards-problem: > <http://lists.xensource.com/archives/html/xen-users/2011-01/msg00375.html>The fix referenced by that thread (which turns out to be http://marc.info/?l=linux-kernel&m=128811236726156&w=2) is upstream as e7a3481c0246c8e45e79c629efd63b168e91fcda but didn''t make it to the stable trees (the resend which was what actually got applied appears to have accidentally dropped the original''s CC:stable@, oops). This is a fix for 489fb490dbf8dab0249ad82b56688ae3842a79e8 which went into 2.6.32.16 as 1345126c761f0360dc108973bf73281d51945bc1 so the timeline fits and the fix seems obviously correct. Greg, please can you queue e7a3481c0246c8e45e79c629efd63b168e91fcda for 2.6.32.y longterm. The fix is already in 2.6.37-rc1 so its not needed for the current stable branch. For completeness 489fb490dbf8dab0249ad82b56688ae3842a79e8 was in v2.6.35-rc1 and was backported to the 2.6.{32,33,34}.y branches while e7a3481c0246c8e45e79c629efd63b168e91fcda was in v2.6.37-rc6 (I presume we are not expected to cc all the longterm maintainers for the various longterm trees and that cc stable@ sufficient) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2011-Jan-28 08:53 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On Thu, Jan 27, 2011 at 06:27:30PM -0500, Konrad Rzeszutek Wilk wrote:> On Thu, Jan 27, 2011 at 02:54:54PM -0800, Nathan March wrote: > > On 1/27/2011 12:57 PM, Ian Campbell wrote: > > > > > >Are the guests 32 or 64 bit? How about the hypervisor and dom0 kernel? > > >What is your kernel''s .config? > > All 64bit. Config is attached. > > > > >If you edit /etc/sysconfig/{xencommons,xend} (whichever one you have) > > >then you can set XENCONSOLED_TRACE=guest which will write guest consoles > > >to /var/log/xen/domain. Also setting "on_crash=preserve" in your guest > > >configuration will hopefully cause them to stick around long enough to > > >see what was on the console. > > > > > Will try that. The domUs don''t actually fully crash, they just lock > > up. The VM keeps running until I destroy it. Trying to attach to the > > console when it''s in this state results in xenconsole hanging on an > > select against fd 3/4/5 (socket, pipe + pipe) > > You could run ''xenctx'' and get a stack trace of what the guest is doing. > That could narrow it down. >xenctx usage is described here: http://wiki.xen.org/xenwiki/XenCommonProblems#head-61843b32f0243b5ad0e17850f9493bffd80f8c17 -- Pasi> > > > I''ll try all the things suggested and let you guys know what I find. > > OK. > > _______________________________________________ > 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
Nathan March
2011-Jan-28 18:44 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
> The fix referenced by that thread (which turns out to be > http://marc.info/?l=linux-kernel&m=128811236726156&w=2) is upstream as > e7a3481c0246c8e45e79c629efd63b168e91fcda but didn''t make it to the > stable trees (the resend which was what actually got applied appears to > have accidentally dropped the original''s CC:stable@, oops). > > This is a fix for 489fb490dbf8dab0249ad82b56688ae3842a79e8 which went > into 2.6.32.16 as 1345126c761f0360dc108973bf73281d51945bc1 so the > timeline fits and the fix seems obviously correctI can confirm that e7a3481c0246c8e45e79c629efd63b168e91fcda has fixed my migration problems. Thanks for all the quick help everyone, very much appreciated. - Nathan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Feb-04 14:17 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
Ping? Thanks, Ian. On Fri, 2011-01-28 at 08:44 +0000, Ian Campbell wrote:> Greg, please can you queue e7a3481c0246c8e45e79c629efd63b168e91fcda for > 2.6.32.y longterm. The fix is already in 2.6.37-rc1 so its not needed > for the current stable branch. > > For completeness 489fb490dbf8dab0249ad82b56688ae3842a79e8 was in > v2.6.35-rc1 and was backported to the 2.6.{32,33,34}.y branches while > e7a3481c0246c8e45e79c629efd63b168e91fcda was in v2.6.37-rc6_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Feb 04, 2011 at 02:17:19PM +0000, Ian Campbell wrote:> Ping?Sorry, I''ve been swamped with "real work" lately and will be getting back to -stable stuff hopefully later today, or next week. Don''t worry, this is in my queue of things to do and not lost. thanks, greg k-h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Feb-04 14:51 UTC
Re: [Xen-devel] Live migration bug introduced in 2.6.32.16?
On Fri, 2011-02-04 at 14:46 +0000, Greg KH wrote:> On Fri, Feb 04, 2011 at 02:17:19PM +0000, Ian Campbell wrote: > > Ping? > > Sorry, I''ve been swamped with "real work" lately and will be getting > back to -stable stuff hopefully later today, or next week. Don''t worry, > this is in my queue of things to do and not lost.Awesome, thanks! Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Jan 28, 2011 at 08:44:20AM +0000, Ian Campbell wrote:> (Please don''t drop CC''s when posting to xen-devel) > > On Fri, 2011-01-28 at 06:47 +0000, Philipp Hahn wrote: > > Hello, > > > > Am Donnerstag 27 Januar 2011 21:21:14 schrieb Nathan March: > > > It looks like a live migration bug may have been introduced in 2.6.32.16... > > ... > > > Note that this isn''t consistent at all, I''ve got 6 dom0''s and this only > > > happens when migrating certain directions between certain dom0''s: > > > > Sounds like a problem very similar to mine. Please check if you have the > > pvclock-going-backwards-problem: > > <http://lists.xensource.com/archives/html/xen-users/2011-01/msg00375.html> > > The fix referenced by that thread (which turns out to be > http://marc.info/?l=linux-kernel&m=128811236726156&w=2) is upstream as > e7a3481c0246c8e45e79c629efd63b168e91fcda but didn''t make it to the > stable trees (the resend which was what actually got applied appears to > have accidentally dropped the original''s CC:stable@, oops). > > This is a fix for 489fb490dbf8dab0249ad82b56688ae3842a79e8 which went > into 2.6.32.16 as 1345126c761f0360dc108973bf73281d51945bc1 so the > timeline fits and the fix seems obviously correct. > > Greg, please can you queue e7a3481c0246c8e45e79c629efd63b168e91fcda for > 2.6.32.y longterm. The fix is already in 2.6.37-rc1 so its not needed > for the current stable branch.Now queued up. thanks, greg k-h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel