Xen devel - Jun 2011 - Question about Xen S3 and resume code - Linux dom0 never exits the xen_safe_halt hypercall after resume

I''ve been eyeing the ACPI S3/S5 code to see what would be necessary to
retool, and while testing I found something strange..

I''ve stuck the code on

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v1

I found out that if I don''t have this patch:

commit 9f301b0a0081676dfc71b7f0898295e6bcba391a
Author: Yu Ke <ke.yu@intel.com>
Date:   Thu Jun 16 17:15:26 2011 -0400

    xen/acpi: add xen acpi processor driver

(which is in the devel/acpi-s3.v0 branch).

the hypervisor, after an S3 resume sits forever in the default_idle. The
Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.

http://darnok.org/xen/devel.acpi-s3.v1.serial.log

If that patch above is present and I''ve cpufreq=xen on the Xen
hypervisor then Linux kernel gets unstuck and returns to userspace:

http://darnok.org/xen/devel.acpi-s3.v0.serial.log

(however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
gets stuck).

I figured that the primary reason the guest is allowed to
exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
acp_processor_idle which does "something" extra after the machine
comes
out of a S3 suspend.

Any ideas?

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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, June 17, 2011 6:58 AM
> 
> I''ve been eyeing the ACPI S3/S5 code to see what would be
necessary to
> retool, and while testing I found something strange..
> 
> I''ve stuck the code on
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/acpi-s3.v1
> 
> I found out that if I don''t have this patch:
> 
> commit 9f301b0a0081676dfc71b7f0898295e6bcba391a
> Author: Yu Ke <ke.yu@intel.com>
> Date:   Thu Jun 16 17:15:26 2011 -0400
> 
>     xen/acpi: add xen acpi processor driver
ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is for
Cx/Px.
> 
> (which is in the devel/acpi-s3.v0 branch).
> 
> the hypervisor, after an S3 resume sits forever in the default_idle. The
> Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> 
> http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> 
> If that patch above is present and I''ve cpufreq=xen on the Xen
> hypervisor then Linux kernel gets unstuck and returns to userspace:
> 
> http://darnok.org/xen/devel.acpi-s3.v0.serial.log
Compare your logs, the major difference is:

[  168.754739] calling  i2c-8+ @ 3096
[  168.758200] call i2c-8+ returned 0 after 0 usecs
<<< 1st case stuck here
[  168.762882] calling  card0-VGA-1+ @ 3096
[  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
[  168.772085] calling  ttm+ @ 3096
[  168.775360] call ttm+ returned 0 after 0 usecs
[  168.779870] PM: resume of devices complete after 13117.603 msecs
[  168.786006] PM: Finishing wakeup.
<<<2nd case forward progress

It looks that VGA card resume has some problem on resume, which then
makes dom0 stay in idle loop and thus block hypercall, and then due to
no runnable vcpu so Xen most time in idle_loop too. In earlier log
there''re
some stack trace in i915 driver. Perhaps you can try a different machine
or try native S3 on same box to make sure it''s not mixed with native
issues.
> 
> (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> gets stuck).
> 
> I figured that the primary reason the guest is allowed to
> exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> acp_processor_idle which does "something" extra after the machine
comes
> out of a S3 suspend.
If that''s the case I think you should disable CONFIG_ACPI_PROCESSOR in
dom0
before incorporating Xen specific version (the patch you tried). We
don''t want
dom0 to play with Cx directly b/c it''s the responsibility of Xen.

Of course we still need figure out why same issues occur with cpuidle=0/
cpufreq=none, which however can be revisited after the basic S3 works. :-)
> 
> Any ideas?
No other ideas for now. From historical view Xen S3 was supported before
Cx/Px, and so it''s expected to work correctly w/o ACPI processor
driver. So
please make sure CONFIG_ACPI_PROCESSOR not enabled in your test for
basic S3.

Thanks
Kevin

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

> ideally ACPI S3/S5 has nothing to do with ACPI processor driver which is
for Cx/Px.
Right..
> 
> > 
> > (which is in the devel/acpi-s3.v0 branch).
> > 
> > the hypervisor, after an S3 resume sits forever in the default_idle.
The
> > Linux dom0 is stuck looping (I think) around SCHEDOP_block hypercall.
> > 
> > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > 
> > If that patch above is present and I''ve cpufreq=xen on the
Xen
> > hypervisor then Linux kernel gets unstuck and returns to userspace:
> > 
> > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> 
> Compare your logs, the major difference is:
> 
> [  168.754739] calling  i2c-8+ @ 3096
> [  168.758200] call i2c-8+ returned 0 after 0 usecs
> <<< 1st case stuck here
> [  168.762882] calling  card0-VGA-1+ @ 3096
> [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> [  168.772085] calling  ttm+ @ 3096
> [  168.775360] call ttm+ returned 0 after 0 usecs
> [  168.779870] PM: resume of devices complete after 13117.603 msecs
> [  168.786006] PM: Finishing wakeup.
> <<<2nd case forward progress
> 
> It looks that VGA card resume has some problem on resume, which then
In both cases - with the patch and without..
> makes dom0 stay in idle loop and thus block hypercall, and then due to
> no runnable vcpu so Xen most time in idle_loop too. In earlier log
there''re
> some stack trace in i915 driver. Perhaps you can try a different machine
Or remove the i915 just to eliminate that.
> or try native S3 on same box to make sure it''s not mixed with
native issues.
> 
> > 
> > (however, if I set cpuidle=0 cpufreq=none on the hypervisor line and
> > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> > gets stuck).
> > 
> > I figured that the primary reason the guest is allowed to
> > exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> > acp_processor_idle which does "something" extra after the
machine comes
> > out of a S3 suspend.
> 
> If that''s the case I think you should disable
CONFIG_ACPI_PROCESSOR in dom0
> before incorporating Xen specific version (the patch you tried). We
don''t want
> dom0 to play with Cx directly b/c it''s the responsibility of Xen.
Huh? You misunderstood me. The ''acpi_processor_idle'' is the
hypervisor''s
idle loop. It can be running inside of that one, or the
''default_idle'' loop. Hence
my question why would that specific hypervisor idle loop make dom0 run nicely
while the default one would not.

In dom0, irregardless of the patches, the ''default_idle'' is
run which makes the
xen_safe_halt paravirt call.
> 
> Of course we still need figure out why same issues occur with cpuidle=0/
> cpufreq=none, which however can be revisited after the basic S3 works. :-)
Right. The end result of those parameters is that the
''default_idle'' in the
hypervisor is choosen instead of the ''acpi_processor_idle''
one.
> 
> > 
> > Any ideas?
> 
> No other ideas for now. From historical view Xen S3 was supported before
Hmm, I am actually tempted to start commenting out code in the
acpi_processor_idle
and seeing what will cause it to have the same failure as
''default_idle''.


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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, June 20, 2011 8:36 PM
> 
> > ideally ACPI S3/S5 has nothing to do with ACPI processor driver which
is for
> Cx/Px.
> 
> Right..
> >
> > >
> > > (which is in the devel/acpi-s3.v0 branch).
> > >
> > > the hypervisor, after an S3 resume sits forever in the
default_idle. The
> > > Linux dom0 is stuck looping (I think) around SCHEDOP_block
hypercall.
> > >
> > > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > >
> > > If that patch above is present and I''ve cpufreq=xen on
the Xen
> > > hypervisor then Linux kernel gets unstuck and returns to
userspace:
> > >
> > > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> >
> > Compare your logs, the major difference is:
> >
> > [  168.754739] calling  i2c-8+ @ 3096
> > [  168.758200] call i2c-8+ returned 0 after 0 usecs
> > <<< 1st case stuck here
> > [  168.762882] calling  card0-VGA-1+ @ 3096
> > [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> > [  168.772085] calling  ttm+ @ 3096
> > [  168.775360] call ttm+ returned 0 after 0 usecs
> > [  168.779870] PM: resume of devices complete after 13117.603 msecs
> > [  168.786006] PM: Finishing wakeup.
> > <<<2nd case forward progress
> >
> > It looks that VGA card resume has some problem on resume, which then
> 
> In both cases - with the patch and without..
that''s expected since device suspend is always invoked in the S3 path.
> 
> > makes dom0 stay in idle loop and thus block hypercall, and then due to
> > no runnable vcpu so Xen most time in idle_loop too. In earlier log
there''re
> > some stack trace in i915 driver. Perhaps you can try a different
machine
> 
> Or remove the i915 just to eliminate that.
So any result there? :-)
> > or try native S3 on same box to make sure it''s not mixed with
native issues.
> >
> > >
> > > (however, if I set cpuidle=0 cpufreq=none on the hypervisor line
and
> > > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it still
> > > gets stuck).
> > >
> > > I figured that the primary reason the guest is allowed to
> > > exit is SCHEDOP_block loop is b/c the pm_idle call is set to the
> > > acp_processor_idle which does "something" extra after
the machine comes
> > > out of a S3 suspend.
> >
> > If that''s the case I think you should disable
CONFIG_ACPI_PROCESSOR in
> dom0
> > before incorporating Xen specific version (the patch you tried). We
don''t want
> > dom0 to play with Cx directly b/c it''s the responsibility of
Xen.
> 
> Huh? You misunderstood me. The ''acpi_processor_idle'' is
the hypervisor''s
> idle loop. It can be running inside of that one, or the
''default_idle'' loop. Hence
running inside which one? I''d think only default_idle invokes it when
current cpu
is actually idle.
> my question why would that specific hypervisor idle loop make dom0 run
nicely
> while the default one would not.
this is counterintuitive to me honestly speaking. I''d more think that 
acpi_processor_idle may cause some issue than pure "sti;hlt" because
acpi
version has more logic to handle. In earlier day when it''s still in
stabilization
phase, we did observe some non-exit case from deep Cstate but this never
happens on pure hlt.

IOW, I don''t take this idle path as a necessary step to make S3 resume
working,
which is simply related when the cpu has nothing to do... 
> 
> In dom0, irregardless of the patches, the ''default_idle''
is run which makes the
> xen_safe_halt paravirt call.
OK, that matches my expectation then.
> 
> >
> > Of course we still need figure out why same issues occur with
cpuidle=0/
> > cpufreq=none, which however can be revisited after the basic S3 works.
:-)
> 
> Right. The end result of those parameters is that the
''default_idle'' in the
> hypervisor is choosen instead of the
''acpi_processor_idle'' one.
> >
> > >
> > > Any ideas?
> >
> > No other ideas for now. From historical view Xen S3 was supported
before
> 
> Hmm, I am actually tempted to start commenting out code in the
> acpi_processor_idle
> and seeing what will cause it to have the same failure as
''default_idle''.
you can also try "max_cstates=1" to see any difference, which is
expected to
has similar effect as safe_halt().

Thanks
Kevin

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

Hi, Konrad,

any update on this S3 problem you''re seeing?

I just got a chance to give a try on my Dell core-i7 platform with a Ubuntu
10.10
system. 

Xen version is:
changeset:   23632:33717472f37e
tag:         tip
user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
date:        Tue Jun 28 18:15:44 2011 +0100
summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h

for dom0 I use origin/master plus ACPI patches queued on your
origin/devel/acpi-s3.v0:
commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
Merge: df5b2b6 9f90a3b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Jun 21 09:34:31 2011 -0400

    Merge branch ''3.0-rc1-rem_pg_reserve-4'' of
git://xenbits.xen.org/people/sstabellini/linux-pvhvm

w/ or w/o ACPI processor patches on my box ACPI S3 just works well.

Thanks
Kevin
> From: Tian, Kevin
> Sent: Tuesday, June 21, 2011 7:22 AM
> 
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Monday, June 20, 2011 8:36 PM
> >
> > > ideally ACPI S3/S5 has nothing to do with ACPI processor driver
which is for
> > Cx/Px.
> >
> > Right..
> > >
> > > >
> > > > (which is in the devel/acpi-s3.v0 branch).
> > > >
> > > > the hypervisor, after an S3 resume sits forever in the
default_idle. The
> > > > Linux dom0 is stuck looping (I think) around SCHEDOP_block
hypercall.
> > > >
> > > > http://darnok.org/xen/devel.acpi-s3.v1.serial.log
> > > >
> > > > If that patch above is present and I''ve cpufreq=xen
on the Xen
> > > > hypervisor then Linux kernel gets unstuck and returns to
userspace:
> > > >
> > > > http://darnok.org/xen/devel.acpi-s3.v0.serial.log
> > >
> > > Compare your logs, the major difference is:
> > >
> > > [  168.754739] calling  i2c-8+ @ 3096
> > > [  168.758200] call i2c-8+ returned 0 after 0 usecs
> > > <<< 1st case stuck here
> > > [  168.762882] calling  card0-VGA-1+ @ 3096
> > > [  168.766867] call card0-VGA-1+ returned 0 after 0 usecs
> > > [  168.772085] calling  ttm+ @ 3096
> > > [  168.775360] call ttm+ returned 0 after 0 usecs
> > > [  168.779870] PM: resume of devices complete after 13117.603
msecs
> > > [  168.786006] PM: Finishing wakeup.
> > > <<<2nd case forward progress
> > >
> > > It looks that VGA card resume has some problem on resume, which
then
> >
> > In both cases - with the patch and without..
> 
> that''s expected since device suspend is always invoked in the S3
path.
> 
> >
> > > makes dom0 stay in idle loop and thus block hypercall, and then
due to
> > > no runnable vcpu so Xen most time in idle_loop too. In earlier
log there''re
> > > some stack trace in i915 driver. Perhaps you can try a different
machine
> >
> > Or remove the i915 just to eliminate that.
> 
> So any result there? :-)
> 
> > > or try native S3 on same box to make sure it''s not mixed
with native issues.
> > >
> > > >
> > > > (however, if I set cpuidle=0 cpufreq=none on the hypervisor
line and
> > > > have the 9f301b0a0081676dfc71b7f0898295e6bcba391a patch it
still
> > > > gets stuck).
> > > >
> > > > I figured that the primary reason the guest is allowed to
> > > > exit is SCHEDOP_block loop is b/c the pm_idle call is set to
the
> > > > acp_processor_idle which does "something" extra
after the machine
> comes
> > > > out of a S3 suspend.
> > >
> > > If that''s the case I think you should disable
CONFIG_ACPI_PROCESSOR in
> > dom0
> > > before incorporating Xen specific version (the patch you tried).
We don''t
> want
> > > dom0 to play with Cx directly b/c it''s the
responsibility of Xen.
> >
> > Huh? You misunderstood me. The ''acpi_processor_idle''
is the hypervisor''s
> > idle loop. It can be running inside of that one, or the
''default_idle'' loop. Hence
> 
> running inside which one? I''d think only default_idle invokes it
when current cpu
> is actually idle.
> 
> > my question why would that specific hypervisor idle loop make dom0 run
> nicely
> > while the default one would not.
> 
> this is counterintuitive to me honestly speaking. I''d more think
that
> acpi_processor_idle may cause some issue than pure "sti;hlt"
because acpi
> version has more logic to handle. In earlier day when it''s still
in stabilization
> phase, we did observe some non-exit case from deep Cstate but this never
> happens on pure hlt.
> 
> IOW, I don''t take this idle path as a necessary step to make S3
resume working,
> which is simply related when the cpu has nothing to do...
> 
> >
> > In dom0, irregardless of the patches, the
''default_idle'' is run which makes the
> > xen_safe_halt paravirt call.
> 
> OK, that matches my expectation then.
> 
> >
> > >
> > > Of course we still need figure out why same issues occur with
cpuidle=0/
> > > cpufreq=none, which however can be revisited after the basic S3
works. :-)
> >
> > Right. The end result of those parameters is that the
''default_idle'' in the
> > hypervisor is choosen instead of the
''acpi_processor_idle'' one.
> > >
> > > >
> > > > Any ideas?
> > >
> > > No other ideas for now. From historical view Xen S3 was supported
before
> >
> > Hmm, I am actually tempted to start commenting out code in the
> > acpi_processor_idle
> > and seeing what will cause it to have the same failure as
''default_idle''.
> 
> you can also try "max_cstates=1" to see any difference, which is
expected to
> has similar effect as safe_halt().
> 
> Thanks
> Kevin
> 
> _______________________________________________
> 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

On Thu, Jun 30, 2011 at 01:34:27PM +0800, Tian, Kevin
wrote:
> Hi, Konrad,
> 
> any update on this S3 problem you''re seeing?
I removed the i915, the USB, and didn''t have any WARN or such in the
bootup. But it still would not get back to the Linux dom0 after a resume.

(http://darnok.org/xen/devel-acpi-s1-no-i915-no-usb.log)
> 
> I just got a chance to give a try on my Dell core-i7 platform with a Ubuntu
10.10
> system. 
> 
> Xen version is:
> changeset:   23632:33717472f37e
> tag:         tip
> user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> date:        Tue Jun 28 18:15:44 2011 +0100
> summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h
> 
> for dom0 I use origin/master plus ACPI patches queued on your
origin/devel/acpi-s3.v0:
<nods> OK, so the working branch.
> commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
> Merge: df5b2b6 9f90a3b
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Tue Jun 21 09:34:31 2011 -0400
> 
>     Merge branch ''3.0-rc1-rem_pg_reserve-4'' of
git://xenbits.xen.org/people/sstabellini/linux-pvhvm
> 
> w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
And without the ACPI proccessor. What ''Dell Core i7'' box is
this? Let me try to get the
OptiPlex 780 I''ve here and see how it fares. Did you use any fancy
patches for the AMT?


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

> > w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
> 
> And without the ACPI proccessor. What ''Dell Core i7'' box
is this? Let me try to get the
> OptiPlex 780 I''ve here and see how it fares. Did you use any fancy
patches for the AMT?
Tried it on a Dell Optiplex 780 and found out that if I use Xen 4.1.1 (but not
Xen-unstable) it suspends and resumes just fine. Albeit I had trouble with the
Intel AMT
but that could be related to something else.

Anyhow going to try this on the SandyBridge box I saw this issue the first time
and I will stick the Xen 4.1.1 instead of Xen unstable on it.


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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, July 01, 2011 12:31 AM
> 
> On Thu, Jun 30, 2011 at 01:34:27PM +0800, Tian, Kevin wrote:
> > Hi, Konrad,
> >
> > any update on this S3 problem you''re seeing?
> 
> I removed the i915, the USB, and didn''t have any WARN or such in
the
> bootup. But it still would not get back to the Linux dom0 after a resume.
> 
> (http://darnok.org/xen/devel-acpi-s1-no-i915-no-usb.log)
S3 is a very fragile feature which highly depends on the platform
implementation.
I''d more think there''s a driver related resume issue which is
incompatible with
Xen in the resume path. I can''t tell why w/ ACPI processor driver it
can forward
progress... perhaps due to more timer activity e.g. from cpufreq timer which
kicks some hanging point...
> 
> >
> > I just got a chance to give a try on my Dell core-i7 platform with a
Ubuntu
> 10.10
> > system.
> >
> > Xen version is:
> > changeset:   23632:33717472f37e
> > tag:         tip
> > user:        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > date:        Tue Jun 28 18:15:44 2011 +0100
> > summary:     libxc: Squash xc_e820.h (and delete) into xenctrl.h
> >
> > for dom0 I use origin/master plus ACPI patches queued on your
> origin/devel/acpi-s3.v0:
> 
> <nods> OK, so the working branch.
> 
> > commit 4aa69dc48e031276b4d771dcb227d553fd3def0b
> > Merge: df5b2b6 9f90a3b
> > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date:   Tue Jun 21 09:34:31 2011 -0400
> >
> >     Merge branch ''3.0-rc1-rem_pg_reserve-4'' of
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm
> >
> > w/ or w/o ACPI processor patches on my box ACPI S3 just works well.
> 
> And without the ACPI proccessor. What ''Dell Core i7'' box
is this? Let me try to
> get the
> OptiPlex 780 I''ve here and see how it fares. Did you use any fancy
patches for
> the AMT?
Have to say I lose the actual name for this box. It''s a "studio
xps" model, with
cpu as "core i7 870 (2.93G)"

there''s no AMT related BIOS option on this box, and thus I
don''t use any other
patches aside. :-)

Thanks
Kevin

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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, July 01, 2011 6:13 AM
> 
> > > w/ or w/o ACPI processor patches on my box ACPI S3 just works
well.
> >
> > And without the ACPI proccessor. What ''Dell Core i7''
box is this? Let me try to
> get the
> > OptiPlex 780 I''ve here and see how it fares. Did you use any
fancy patches for
> the AMT?
> 
> Tried it on a Dell Optiplex 780 and found out that if I use Xen 4.1.1 (but
not
> Xen-unstable) it suspends and resumes just fine. Albeit I had trouble with
the
> Intel AMT
> but that could be related to something else.
that''s good news. at least you have a stable environment now when you
work on
upstreaming it. :-)
> 
> Anyhow going to try this on the SandyBridge box I saw this issue the first
time
> and I will stick the Xen 4.1.1 instead of Xen unstable on it.
that''s fine. I''ll see whether I can find other boxes with same
issue as you observed.

Thanks
Kevin

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