Re: [Xen-users] svm.c:83:d917 Bad instruction length 0

Re: [Xen-users] svm.c:83:d917 Bad instruction length 0

[Russ Blaine]

[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

Re: [Xen-devel] Re: svm.c:83:d917 Bad instruction length 0

[Keir Fraser]

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

Re: Re: [Xen-users] svm.c:83:d917 Bad instruction length 0

[Russ Blaine]

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

Re: Re: [Xen-users] svm.c:83:d917 Bad instruction length 0

[Jan Beulich]

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

RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0

[James Harper]

> 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

RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0

[Jan Beulich]

>>> "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

Re: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0

[Russ Blaine]

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

RE: Re: [Xen-users] svm.c:83:d917 Bad instructionlength 0

[James Harper]

> 
> > 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