This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Ke

To: JBeulich <JBeulich@xxxxxxxxxx>
Subject: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Kernel?
From: "Carsten Schiers" <carsten@xxxxxxxxxx>
Date: Tue, 14 Sep 2010 11:10:21 +0200
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 14 Sep 2010 02:11:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C8A0C2C0200007800015607@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

I am still trying to solve this issue.

> I'm really surprised you (they) get away with this on a native 

I think I now know. I found the BIOS option that causes the problem: 
SpeedStep. The buggy table
is the description of the C-States. But there is a different behavior 
between native and Xen.
See native here with acpi debug enabled:

[    0.358790] Table [SSDT](id 000C) - 6 Objects with 0 Devices 4 
Methods 0 Regions
[    0.358793]   nsload-0136 [10] ns_load_table         : **** Completed 
Table Method Parsing and Object Initialization
[    0.358944] processor_throttling-1143 [00] processor_get_throttli: 
pblk_address[0x00000810] duty_offset[1] duty_width[0]
[    0.358952] processor_throttling-0893 [00] processor_get_fadt_inf: No 
throttling states
[    0.358959] processor_idle-0361 [00] processor_get_power_in: No _CST, 
giving up
[    0.358963] processor_idle-0317 [00] processor_get_power_in: C2 
latency too large [101]
[    0.358967] processor_idle-0325 [00] processor_get_power_in: 
lvl2[0x00000000] lvl3[0x00000815]
[    0.358972] processor_idle-0548 [00] processor_power_verify: latency 
too large [1001]

No _CST, giving up, C2 too large (0x80000000, I guess), giving up. Xen 
doesn't give up.

I did not manage to create the same with Xen, as it will not appear in 
the serial log. It will show in dmesg, if it comes
up, but unfortunately, it will crash with SpeedStep enabled, but not 
interpret SSDT1 if disabled, thus no information. 

BR, Carsten.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>