1 |
symack <symack@×××××.com> writes: |
2 |
|
3 |
> the only thing is when we try to boot with xen, it gets to the prompt and |
4 |
> then reboots |
5 |
> by itself. The following message is what differs between normal gentoo and |
6 |
> xen kernel |
7 |
> |
8 |
> Mar 31 06:32:18 test kernel: [ 0.138644] ACPI Exception: AE_NOT_FOUND, |
9 |
> While evaluating Sleep State [\_S1_] (20140724/hwxface-580) |
10 |
> Mar 31 06:32:18 test kernel: [ 0.138961] ACPI Exception: AE_NOT_FOUND, |
11 |
> While evaluating Sleep State [\_S2_] (20140724/hwxface-580) |
12 |
> Mar 31 06:32:18 test kernel: [ 0.139267] ACPI Exception: AE_NOT_FOUND, |
13 |
> While evaluating Sleep State [\_S3_] (20140724/hwxface-580) |
14 |
|
15 |
There is a kernel boot parameter which you can use to prevent the xen |
16 |
kernel from attempting power management --- though IIRC that was more |
17 |
related to frequency settings. |
18 |
|
19 |
As far as I was able to figure out, you have two options: Either xen |
20 |
sets frequencies, or dom0 does. If the latter, all CPUs must be |
21 |
available to dom0. However, currently nobody seems to know exactly what |
22 |
xen does towards frequency setting. |
23 |
|
24 |
|
25 |
And if I'm not horribly mistaken, there is a way to do something about |
26 |
what xen considers as usable, or available, cpu states. It was |
27 |
something along the lines that xen might not detect all possible cpu |
28 |
states, and you could do something to tell it that there are more states |
29 |
than it detects. Perhaps it's also possible to limit xen to S0. |
30 |
|
31 |
First I would look into updating the BIOS. If that doesn't help, I'd |
32 |
try to limit xen to S0. |
33 |
|
34 |
Other than that, unless you really do need full virtualization: I'm |
35 |
finding Linux containers to be far more manageable than virtual |
36 |
machines, and much more efficient. |
37 |
|
38 |
|
39 |
-- |
40 |
Again we must be afraid of speaking of daemons for fear that daemons |
41 |
might swallow us. Finally, this fear has become reasonable. |