AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?

["Carsten Schiers" <carsten@xxxxxxxxxx>]

Hi,

I am still trying to solve this issue.

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

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel