* Re: [Xen-users] svm.c:83:d917 Bad instruction length 0 [not found] ` <515922b50808050756j7bdbf4b7we9de796fd97c79db@mail.gmail.com> @ 2008-08-08 19:14 ` Russ Blaine 2008-08-08 19:22 ` [Xen-devel] " Keir Fraser 0 siblings, 1 reply; 8+ messages in thread From: Russ Blaine @ 2008-08-08 19:14 UTC (permalink / raw) To: Trolle Selander; +Cc: xen-devel, James Harper, xen-users [moving this thread over to xen-devel] Debug keys output on the crashed domain is: (xVM) svm.c:77:d3 Bad instruction length 0 (xVM) domain_crash called from svm.c:78 (xVM) Domain 3 (vcpu#0) crashed on cpu#1: (xVM) ----[ Xen-3.1.4-xvm x86_64 debug=n Not tainted ]---- (xVM) CPU: 1 (xVM) RIP: 001b:[<0000000072bcaffa>] (xVM) RFLAGS: 0000000000000246 CONTEXT: hvm (xVM) rax: 0000000000040f12 rbx: 0000000001010800 rcx: 0000000000002001 (xVM) rdx: 00000000078bfbff rsi: 0000000072bcaf84 rdi: 0000000000000002 (xVM) rbp: 000000000075f1b0 rsp: 000000000075f190 r8: 0000000000000000 (xVM) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (xVM) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (xVM) r15: 0000000000000000 cr0: 000000008001003b cr4: 00000000000006b9 (xVM) cr3: 000000007fab7280 cr2: 0000000072c353bc (xVM) ds: 732f es: ffff fs: ffff gs: bbff ss: 0023 cs: 001b (xVM) Guest stack trace from rbp=000000000075f1b0: (xVM) 72c333d472bcac5f ???????????????? (xVM) Xen stack trace from rsp=0000000089b8cb48: (xVM) 9090f460841b6124 000004a080000000 0000000084e2b1f8 (xVM) 0000000000000005 89b8cbbc00000001 00000000816a1632 (xVM) 72c353bc84ab51f0 000000006b12f225 c03961a800000000 (xVM) 0000000089b8cd64 841b613089b8cbc8 00000000845bf368 (xVM) 0000000000000000 800000006b12f225 89b8cc08841b3fe4 (xVM) 00000000816a250d 9090f46072c353bc 0000000084ab51f0 (xVM) 89b8cc6089b8cd64 c03961a884ab9a90 000000019090f460 (xVM) 0000000500000000 000007d06b12f8a4 9090f46000000800 (xVM) 8169f99f89b8ccd0 72c353bc00000000 84ab51f0c03961a8 (xVM) 9090f46000000000 89b8cc6089b8cd64 0000010000000000 (xVM) 00000110c03961a8 9090f46000000000 81713802c0484878 (xVM) 9090f4606b12f8a4 0000000089b8cd4c c03961a880354000 (xVM) 0000000000000000 8443ee008166e9be 89b8cd4c000000b2 (xVM) badb0d00816c12c9 8f27d19000000000 8f27d17884ab9a90 (xVM) 000201e08f280418 0000000084ab9a90 8183873f00000000 (xVM) 89b8ccc80000020c 84ab523000000000 84e2d3186a7fd867 (xVM) 0000001889b8cce0 816c1fff89b8cd4c 9090f46072c353bc (xVM) 84ab51f000000000 84e2d31889b8cd64 0000000072c353bc (xVM) 89b8ccfc0075f23c 0000000000000110 84ab5020c03961a8 (xVM) 0000010084e2d318 000000209090f460 84ab9a9084ab5230 (xVM) Xen call trace: (xVM) [<00000000816a272d>] ??? (xVM) Trolle Selander wrote: > The easiest (*cough*) way is usually to put in some code before the > domain_crash(curr->domain) that dumps the bytes around the eip, but of > course that requires that you rebuild xen from source. One fairly > painless thing that you could do to at least get a hint of what might be > going on is to set on_crash = 'preserve' in the VM configuration file. > That way, after it's crashed, you can do an "xm debug-key v" and get > some information about the last vmexit, which will at least tell us what > type of instruction it was that caused the vmexit. > > On Tue, Aug 5, 2008 at 1:39 AM, James Harper > <james.harper@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> > wrote: > > > > > In 3.2.2-rc2-pre, an instruction length of 0 doesn't cause a guest > crash, > > but rather a retry of the instruction. This was introduced in cs > 16898. > > That said, in 3.2 and older svm.c has a bunch of special case > emulation > > code for system instructions, some of which is quite > incomplete/incorrect. > > 3.3 will be much improved in this regard. In any case, a dump of the > > instruction bytes surrounding the eip would be necessary to determine > what > > the cause was in this particular case. > > > > How easy is it to get that information? > > The annoying thing in this case is that it worked under 3.1.[12]. > > Thanks > > James > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users -- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xen-devel] Re: svm.c:83:d917 Bad instruction length 0 2008-08-08 19:14 ` [Xen-users] svm.c:83:d917 Bad instruction length 0 Russ Blaine @ 2008-08-08 19:22 ` Keir Fraser 2008-08-08 19:35 ` Re: [Xen-users] " Russ Blaine 0 siblings, 1 reply; 8+ messages in thread From: Keir Fraser @ 2008-08-08 19:22 UTC (permalink / raw) To: Russ Blaine, Trolle Selander; +Cc: xen-devel, xen-users, James Harper Realistically you're not likely to get much help with this type of issue on 3.1 branch since it is no longer being maintained. Reproducing it on tip of 3.2-testing would be more interesting since will be doing another release from that branch in the next few weeks. We'd also need more details on the repro scenario. -- Keir On 8/8/08 20:14, "Russ Blaine" <russell.blaine@sun.com> wrote: > [moving this thread over to xen-devel] > > Debug keys output on the crashed domain is: > > (xVM) svm.c:77:d3 Bad instruction length 0 > (xVM) domain_crash called from svm.c:78 > (xVM) Domain 3 (vcpu#0) crashed on cpu#1: > (xVM) ----[ Xen-3.1.4-xvm x86_64 debug=n Not tainted ]---- > (xVM) CPU: 1 > (xVM) RIP: 001b:[<0000000072bcaffa>] > (xVM) RFLAGS: 0000000000000246 CONTEXT: hvm > (xVM) rax: 0000000000040f12 rbx: 0000000001010800 rcx: 0000000000002001 > (xVM) rdx: 00000000078bfbff rsi: 0000000072bcaf84 rdi: 0000000000000002 > (xVM) rbp: 000000000075f1b0 rsp: 000000000075f190 r8: 0000000000000000 > (xVM) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > (xVM) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 > (xVM) r15: 0000000000000000 cr0: 000000008001003b cr4: 00000000000006b9 > (xVM) cr3: 000000007fab7280 cr2: 0000000072c353bc > (xVM) ds: 732f es: ffff fs: ffff gs: bbff ss: 0023 cs: 001b > (xVM) Guest stack trace from rbp=000000000075f1b0: > (xVM) 72c333d472bcac5f ???????????????? > (xVM) Xen stack trace from rsp=0000000089b8cb48: > (xVM) 9090f460841b6124 000004a080000000 0000000084e2b1f8 > (xVM) 0000000000000005 89b8cbbc00000001 00000000816a1632 > (xVM) 72c353bc84ab51f0 000000006b12f225 c03961a800000000 > (xVM) 0000000089b8cd64 841b613089b8cbc8 00000000845bf368 > (xVM) 0000000000000000 800000006b12f225 89b8cc08841b3fe4 > (xVM) 00000000816a250d 9090f46072c353bc 0000000084ab51f0 > (xVM) 89b8cc6089b8cd64 c03961a884ab9a90 000000019090f460 > (xVM) 0000000500000000 000007d06b12f8a4 9090f46000000800 > (xVM) 8169f99f89b8ccd0 72c353bc00000000 84ab51f0c03961a8 > (xVM) 9090f46000000000 89b8cc6089b8cd64 0000010000000000 > (xVM) 00000110c03961a8 9090f46000000000 81713802c0484878 > (xVM) 9090f4606b12f8a4 0000000089b8cd4c c03961a880354000 > (xVM) 0000000000000000 8443ee008166e9be 89b8cd4c000000b2 > (xVM) badb0d00816c12c9 8f27d19000000000 8f27d17884ab9a90 > (xVM) 000201e08f280418 0000000084ab9a90 8183873f00000000 > (xVM) 89b8ccc80000020c 84ab523000000000 84e2d3186a7fd867 > (xVM) 0000001889b8cce0 816c1fff89b8cd4c 9090f46072c353bc > (xVM) 84ab51f000000000 84e2d31889b8cd64 0000000072c353bc > (xVM) 89b8ccfc0075f23c 0000000000000110 84ab5020c03961a8 > (xVM) 0000010084e2d318 000000209090f460 84ab9a9084ab5230 > (xVM) Xen call trace: > (xVM) [<00000000816a272d>] ??? > (xVM) > > > Trolle Selander wrote: >> The easiest (*cough*) way is usually to put in some code before the >> domain_crash(curr->domain) that dumps the bytes around the eip, but of >> course that requires that you rebuild xen from source. One fairly >> painless thing that you could do to at least get a hint of what might be >> going on is to set on_crash = 'preserve' in the VM configuration file. >> That way, after it's crashed, you can do an "xm debug-key v" and get >> some information about the last vmexit, which will at least tell us what >> type of instruction it was that caused the vmexit. >> >> On Tue, Aug 5, 2008 at 1:39 AM, James Harper >> <james.harper@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >> wrote: >> >>> >>> In 3.2.2-rc2-pre, an instruction length of 0 doesn't cause a guest >> crash, >>> but rather a retry of the instruction. This was introduced in cs >> 16898. >>> That said, in 3.2 and older svm.c has a bunch of special case >> emulation >>> code for system instructions, some of which is quite >> incomplete/incorrect. >>> 3.3 will be much improved in this regard. In any case, a dump of the >>> instruction bytes surrounding the eip would be necessary to determine >> what >>> the cause was in this particular case. >>> >> >> How easy is it to get that information? >> >> The annoying thing in this case is that it worked under 3.1.[12]. >> >> Thanks >> >> James >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [Xen-users] svm.c:83:d917 Bad instruction length 0 2008-08-08 19:22 ` [Xen-devel] " Keir Fraser @ 2008-08-08 19:35 ` Russ Blaine 2008-08-11 7:10 ` Jan Beulich 0 siblings, 1 reply; 8+ messages in thread From: Russ Blaine @ 2008-08-08 19:35 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel, Trolle Selander, James Harper The original poster sees the issues on 3.2.1-2 / Debian Lenny. I'm talking with some folks at AMD to see if they can help investigate. In the meantime, I'll be trying to gather some more useful data about the crashing insn. - Russ Keir Fraser wrote: > Realistically you're not likely to get much help with this type of issue on > 3.1 branch since it is no longer being maintained. Reproducing it on tip of > 3.2-testing would be more interesting since will be doing another release > from that branch in the next few weeks. We'd also need more details on the > repro scenario. > > -- Keir > > On 8/8/08 20:14, "Russ Blaine" <russell.blaine@sun.com> wrote: > >> [moving this thread over to xen-devel] >> >> Debug keys output on the crashed domain is: >> >> (xVM) svm.c:77:d3 Bad instruction length 0 >> (xVM) domain_crash called from svm.c:78 >> (xVM) Domain 3 (vcpu#0) crashed on cpu#1: >> (xVM) ----[ Xen-3.1.4-xvm x86_64 debug=n Not tainted ]---- >> (xVM) CPU: 1 >> (xVM) RIP: 001b:[<0000000072bcaffa>] >> (xVM) RFLAGS: 0000000000000246 CONTEXT: hvm >> (xVM) rax: 0000000000040f12 rbx: 0000000001010800 rcx: 0000000000002001 >> (xVM) rdx: 00000000078bfbff rsi: 0000000072bcaf84 rdi: 0000000000000002 >> (xVM) rbp: 000000000075f1b0 rsp: 000000000075f190 r8: 0000000000000000 >> (xVM) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >> (xVM) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >> (xVM) r15: 0000000000000000 cr0: 000000008001003b cr4: 00000000000006b9 >> (xVM) cr3: 000000007fab7280 cr2: 0000000072c353bc >> (xVM) ds: 732f es: ffff fs: ffff gs: bbff ss: 0023 cs: 001b >> (xVM) Guest stack trace from rbp=000000000075f1b0: >> (xVM) 72c333d472bcac5f ???????????????? >> (xVM) Xen stack trace from rsp=0000000089b8cb48: >> (xVM) 9090f460841b6124 000004a080000000 0000000084e2b1f8 >> (xVM) 0000000000000005 89b8cbbc00000001 00000000816a1632 >> (xVM) 72c353bc84ab51f0 000000006b12f225 c03961a800000000 >> (xVM) 0000000089b8cd64 841b613089b8cbc8 00000000845bf368 >> (xVM) 0000000000000000 800000006b12f225 89b8cc08841b3fe4 >> (xVM) 00000000816a250d 9090f46072c353bc 0000000084ab51f0 >> (xVM) 89b8cc6089b8cd64 c03961a884ab9a90 000000019090f460 >> (xVM) 0000000500000000 000007d06b12f8a4 9090f46000000800 >> (xVM) 8169f99f89b8ccd0 72c353bc00000000 84ab51f0c03961a8 >> (xVM) 9090f46000000000 89b8cc6089b8cd64 0000010000000000 >> (xVM) 00000110c03961a8 9090f46000000000 81713802c0484878 >> (xVM) 9090f4606b12f8a4 0000000089b8cd4c c03961a880354000 >> (xVM) 0000000000000000 8443ee008166e9be 89b8cd4c000000b2 >> (xVM) badb0d00816c12c9 8f27d19000000000 8f27d17884ab9a90 >> (xVM) 000201e08f280418 0000000084ab9a90 8183873f00000000 >> (xVM) 89b8ccc80000020c 84ab523000000000 84e2d3186a7fd867 >> (xVM) 0000001889b8cce0 816c1fff89b8cd4c 9090f46072c353bc >> (xVM) 84ab51f000000000 84e2d31889b8cd64 0000000072c353bc >> (xVM) 89b8ccfc0075f23c 0000000000000110 84ab5020c03961a8 >> (xVM) 0000010084e2d318 000000209090f460 84ab9a9084ab5230 >> (xVM) Xen call trace: >> (xVM) [<00000000816a272d>] ??? >> (xVM) >> >> >> Trolle Selander wrote: >>> The easiest (*cough*) way is usually to put in some code before the >>> domain_crash(curr->domain) that dumps the bytes around the eip, but of >>> course that requires that you rebuild xen from source. One fairly >>> painless thing that you could do to at least get a hint of what might be >>> going on is to set on_crash = 'preserve' in the VM configuration file. >>> That way, after it's crashed, you can do an "xm debug-key v" and get >>> some information about the last vmexit, which will at least tell us what >>> type of instruction it was that caused the vmexit. >>> >>> On Tue, Aug 5, 2008 at 1:39 AM, James Harper >>> <james.harper@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >>> wrote: >>> >>>> In 3.2.2-rc2-pre, an instruction length of 0 doesn't cause a guest >>> crash, >>>> but rather a retry of the instruction. This was introduced in cs >>> 16898. >>>> That said, in 3.2 and older svm.c has a bunch of special case >>> emulation >>>> code for system instructions, some of which is quite >>> incomplete/incorrect. >>>> 3.3 will be much improved in this regard. In any case, a dump of the >>>> instruction bytes surrounding the eip would be necessary to determine >>> what >>>> the cause was in this particular case. >>>> >>> How easy is it to get that information? >>> >>> The annoying thing in this case is that it worked under 3.1.[12]. >>> >>> Thanks >>> >>> James >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users -- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [Xen-users] svm.c:83:d917 Bad instruction length 0 2008-08-08 19:35 ` Re: [Xen-users] " Russ Blaine @ 2008-08-11 7:10 ` Jan Beulich 2008-08-11 7:25 ` Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 James Harper 2008-08-19 1:14 ` James Harper 0 siblings, 2 replies; 8+ messages in thread From: Jan Beulich @ 2008-08-11 7:10 UTC (permalink / raw) To: Russ Blaine; +Cc: xen-devel, James Harper, Trolle Selander, Keir Fraser We had reports on this (against 3.2.0) too, and this ought to be fixed in 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of instructions starting close to a page boundary was broken. Jan >>> Russ Blaine <russell.blaine@sun.com> 08.08.08 21:35 >>> The original poster sees the issues on 3.2.1-2 / Debian Lenny. I'm talking with some folks at AMD to see if they can help investigate. In the meantime, I'll be trying to gather some more useful data about the crashing insn. - Russ Keir Fraser wrote: > Realistically you're not likely to get much help with this type of issue on > 3.1 branch since it is no longer being maintained. Reproducing it on tip of > 3.2-testing would be more interesting since will be doing another release > from that branch in the next few weeks. We'd also need more details on the > repro scenario. > > -- Keir > > On 8/8/08 20:14, "Russ Blaine" <russell.blaine@sun.com> wrote: > >> [moving this thread over to xen-devel] >> >> Debug keys output on the crashed domain is: >> >> (xVM) svm.c:77:d3 Bad instruction length 0 >> (xVM) domain_crash called from svm.c:78 >> (xVM) Domain 3 (vcpu#0) crashed on cpu#1: >> (xVM) ----[ Xen-3.1.4-xvm x86_64 debug=n Not tainted ]---- >> (xVM) CPU: 1 >> (xVM) RIP: 001b:[<0000000072bcaffa>] >> (xVM) RFLAGS: 0000000000000246 CONTEXT: hvm >> (xVM) rax: 0000000000040f12 rbx: 0000000001010800 rcx: 0000000000002001 >> (xVM) rdx: 00000000078bfbff rsi: 0000000072bcaf84 rdi: 0000000000000002 >> (xVM) rbp: 000000000075f1b0 rsp: 000000000075f190 r8: 0000000000000000 >> (xVM) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 >> (xVM) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 >> (xVM) r15: 0000000000000000 cr0: 000000008001003b cr4: 00000000000006b9 >> (xVM) cr3: 000000007fab7280 cr2: 0000000072c353bc >> (xVM) ds: 732f es: ffff fs: ffff gs: bbff ss: 0023 cs: 001b >> (xVM) Guest stack trace from rbp=000000000075f1b0: >> (xVM) 72c333d472bcac5f ???????????????? >> (xVM) Xen stack trace from rsp=0000000089b8cb48: >> (xVM) 9090f460841b6124 000004a080000000 0000000084e2b1f8 >> (xVM) 0000000000000005 89b8cbbc00000001 00000000816a1632 >> (xVM) 72c353bc84ab51f0 000000006b12f225 c03961a800000000 >> (xVM) 0000000089b8cd64 841b613089b8cbc8 00000000845bf368 >> (xVM) 0000000000000000 800000006b12f225 89b8cc08841b3fe4 >> (xVM) 00000000816a250d 9090f46072c353bc 0000000084ab51f0 >> (xVM) 89b8cc6089b8cd64 c03961a884ab9a90 000000019090f460 >> (xVM) 0000000500000000 000007d06b12f8a4 9090f46000000800 >> (xVM) 8169f99f89b8ccd0 72c353bc00000000 84ab51f0c03961a8 >> (xVM) 9090f46000000000 89b8cc6089b8cd64 0000010000000000 >> (xVM) 00000110c03961a8 9090f46000000000 81713802c0484878 >> (xVM) 9090f4606b12f8a4 0000000089b8cd4c c03961a880354000 >> (xVM) 0000000000000000 8443ee008166e9be 89b8cd4c000000b2 >> (xVM) badb0d00816c12c9 8f27d19000000000 8f27d17884ab9a90 >> (xVM) 000201e08f280418 0000000084ab9a90 8183873f00000000 >> (xVM) 89b8ccc80000020c 84ab523000000000 84e2d3186a7fd867 >> (xVM) 0000001889b8cce0 816c1fff89b8cd4c 9090f46072c353bc >> (xVM) 84ab51f000000000 84e2d31889b8cd64 0000000072c353bc >> (xVM) 89b8ccfc0075f23c 0000000000000110 84ab5020c03961a8 >> (xVM) 0000010084e2d318 000000209090f460 84ab9a9084ab5230 >> (xVM) Xen call trace: >> (xVM) [<00000000816a272d>] ??? >> (xVM) >> >> >> Trolle Selander wrote: >>> The easiest (*cough*) way is usually to put in some code before the >>> domain_crash(curr->domain) that dumps the bytes around the eip, but of >>> course that requires that you rebuild xen from source. One fairly >>> painless thing that you could do to at least get a hint of what might be >>> going on is to set on_crash = 'preserve' in the VM configuration file. >>> That way, after it's crashed, you can do an "xm debug-key v" and get >>> some information about the last vmexit, which will at least tell us what >>> type of instruction it was that caused the vmexit. >>> >>> On Tue, Aug 5, 2008 at 1:39 AM, James Harper >>> <james.harper@bendigoit.com.au <mailto:james.harper@bendigoit.com.au>> >>> wrote: >>> >>>> In 3.2.2-rc2-pre, an instruction length of 0 doesn't cause a guest >>> crash, >>>> but rather a retry of the instruction. This was introduced in cs >>> 16898. >>>> That said, in 3.2 and older svm.c has a bunch of special case >>> emulation >>>> code for system instructions, some of which is quite >>> incomplete/incorrect. >>>> 3.3 will be much improved in this regard. In any case, a dump of the >>>> instruction bytes surrounding the eip would be necessary to determine >>> what >>>> the cause was in this particular case. >>>> >>> How easy is it to get that information? >>> >>> The annoying thing in this case is that it worked under 3.1.[12]. >>> >>> Thanks >>> >>> James >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users -- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 2008-08-11 7:10 ` Jan Beulich @ 2008-08-11 7:25 ` James Harper 2008-08-11 7:34 ` Jan Beulich 2008-08-19 1:14 ` James Harper 1 sibling, 1 reply; 8+ messages in thread From: James Harper @ 2008-08-11 7:25 UTC (permalink / raw) To: Jan Beulich, Russ Blaine; +Cc: xen-devel, Trolle Selander, Keir Fraser > We had reports on this (against 3.2.0) too, and this ought to be fixed in > 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of > instructions starting close to a page boundary was broken. Jan I've just applied 16898 to the Debian sources for 3.2.1 and am building now... do you remember if there were any other dependencies? Thanks James ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 2008-08-11 7:25 ` Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 James Harper @ 2008-08-11 7:34 ` Jan Beulich 2008-08-12 17:15 ` Russ Blaine 0 siblings, 1 reply; 8+ messages in thread From: Jan Beulich @ 2008-08-11 7:34 UTC (permalink / raw) To: James Harper; +Cc: Russ Blaine, xen-devel, Trolle Selander, Keir Fraser >>> "James Harper" <james.harper@bendigoit.com.au> 11.08.08 09:25 >>> >> We had reports on this (against 3.2.0) too, and this ought to be fixed >in >> 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of >> instructions starting close to a page boundary was broken. Jan > >I've just applied 16898 to the Debian sources for 3.2.1 and am building >now... do you remember if there were any other dependencies? I don't recall any. Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 2008-08-11 7:34 ` Jan Beulich @ 2008-08-12 17:15 ` Russ Blaine 0 siblings, 0 replies; 8+ messages in thread From: Russ Blaine @ 2008-08-12 17:15 UTC (permalink / raw) To: Jan Beulich Cc: xen-users, James Harper, Trolle Selander, xen-devel, Keir Fraser I traced the issue to __get_instruction_length_from_list() failing to copy the instruction from the guest. AMD pointed out the relevant changeset, and with that changeset ported to our 3.1.4-based implementation, win 2008 can now boot completely without crashing the domain. Thanks... Jan Beulich wrote: >>>> "James Harper" <james.harper@bendigoit.com.au> 11.08.08 09:25 >>> >>> We had reports on this (against 3.2.0) too, and this ought to be fixed >> in >>> 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of >>> instructions starting close to a page boundary was broken. Jan >> I've just applied 16898 to the Debian sources for 3.2.1 and am building >> now... do you remember if there were any other dependencies? > > I don't recall any. Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel -- ----------------------------------------------------- Russ Blaine | Solaris Kernel | russell.blaine@sun.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 2008-08-11 7:10 ` Jan Beulich 2008-08-11 7:25 ` Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 James Harper @ 2008-08-19 1:14 ` James Harper 1 sibling, 0 replies; 8+ messages in thread From: James Harper @ 2008-08-19 1:14 UTC (permalink / raw) To: James Harper, Jan Beulich, Russ Blaine Cc: xen-devel, Trolle Selander, Keir Fraser > > > We had reports on this (against 3.2.0) too, and this ought to be fixed > in > > 3.2.2 (with c/s 16898, closely after 3.2.1 released) - the decoding of > > instructions starting close to a page boundary was broken. Jan > > I've just applied 16898 to the Debian sources for 3.2.1 and am building > now... do you remember if there were any other dependencies? > I finally got a chance to reboot and test this. I would normally get a crash before I am able to log in, but with 16898 applied I am able to log in and join the domain, so I think it's fixed. James ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-08-19 1:14 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AEC6C66638C05B468B556EA548C1A77D0149013B@trantor>
[not found] ` <515922b50808040430k19a9539fu195286be5c7141e1@mail.gmail.com>
[not found] ` <AEC6C66638C05B468B556EA548C1A77D0149016D@trantor>
[not found] ` <515922b50808050756j7bdbf4b7we9de796fd97c79db@mail.gmail.com>
2008-08-08 19:14 ` [Xen-users] svm.c:83:d917 Bad instruction length 0 Russ Blaine
2008-08-08 19:22 ` [Xen-devel] " Keir Fraser
2008-08-08 19:35 ` Re: [Xen-users] " Russ Blaine
2008-08-11 7:10 ` Jan Beulich
2008-08-11 7:25 ` Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0 James Harper
2008-08-11 7:34 ` Jan Beulich
2008-08-12 17:15 ` Russ Blaine
2008-08-19 1:14 ` James Harper
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.