From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Wundram Subject: Re: Re: computer stalls instead of reboot Date: Fri, 09 Sep 2011 15:52:10 +0200 Message-ID: <4E6A1A0A.5040401@modelnine.org> References: <4E694CFB.1060203@citrix.com> <4E6A0034.10706@citrix.com> <4E6A1549.90806@modelnine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. > 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. -- --- Heiko.