From: "Sven Köhler" <sven.koehler@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: computer stalls instead of reboot
Date: Fri, 09 Sep 2011 16:13:35 +0200 [thread overview]
Message-ID: <j4d6ug$ceq$1@dough.gmane.org> (raw)
In-Reply-To: <4E6A1A0A.5040401@modelnine.org>
Am 09.09.2011 15:52, schrieb Heiko Wundram:
> Am 09.09.2011 15:45, schrieb Sven Köhler:
>> I wonder, what the disadvantage are.
>> The hypervisor will still regulate CPU frequency, will it not?
>
> No, it will not.
In xen 3.x, the hypervisor did the cpufreq-like CPU frequency switching.
Has this changes in xen 4.x and the dom0 kernel is now responsible?
>> Also, is the dom0 kernel doing something that it shouldn't do?
>> (maybe something that collides with the ACPI-related activities of the
>> hypervisor, if there are any?)
>
> I guess the BIOS is simply reporting broken ACPI tables to the operating
> system (the board is a "consumer" board, so you can guess that the
> manufacturer only tests the ACPI-tables for compatability with Windows).
>
> The ACPI tables (AFAIK, someone correct me) also contain a method for
> rebooting the system, which simply doesn't work/is broken when Xen is
> involved. Forcing acpi=off means that the normal triple-fault or
> kbd-controller reset machinery is always used, as ACPI isn't even
> initialized.
>
> What struck me as odd, though: you can configure Linux to use "some
> other" form of hard reset through a kernel parameter, but setting that
> to explicitly use triple-faults didn't work, either (same hangs), so
> possibly it's some form of additional interaction between Xen, the board
> and the hypervisor. Anyway, the Hetzner "recommended" fix is just what I
> sent you, and I can confirm that works.
Thanks for the explanation.
Here's another thing: why does rebooting work, if xen is not involved,
i.e. if the same kernel runs without xen? (I'm pretty sure this was true
the last time I tried) I would assume, that broken ACPI tables would
result in no reboot no matter what.
Also, does the dom0 kernel do the reboot, or the hypervisor?
In the past, there were some reboot/poweroff related patches for the xen
part of the kernel. I assumed, that the dom0 kernel is not using the
"normal" reboot/poweroff code and instead instructs the hypervisor
reboot/poweroff the machine.
On the other hand, all the patches that went into linux 3.0 which were
aimed at making poweroff/reboot as similar to windows as possible
sounded promising, but didn't help in the Hetzner case :-(
Regards,
Sven
next prev parent reply other threads:[~2011-09-09 14:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 23:15 computer stalls instead of reboot Sven Köhler
2011-09-08 23:17 ` Andrew Cooper
2011-09-08 23:40 ` Sven Köhler
2011-09-09 12:01 ` Andrew Cooper
2011-09-09 12:55 ` Sven Köhler
2011-09-09 13:31 ` Heiko Wundram
2011-09-09 13:45 ` Sven Köhler
2011-09-09 13:52 ` Heiko Wundram
2011-09-09 14:13 ` Sven Köhler [this message]
2011-09-11 0:55 ` Sven Köhler
2011-09-11 0:57 ` Sven Köhler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='j4d6ug$ceq$1@dough.gmane.org' \
--to=sven.koehler@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).