From owner-freebsd-bugs@FreeBSD.ORG Tue Mar 28 20:10:19 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8657B16A420 for ; Tue, 28 Mar 2006 20:10:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 382A343D68 for ; Tue, 28 Mar 2006 20:10:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2SKAIdl012837 for ; Tue, 28 Mar 2006 20:10:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2SKAI1Y012836; Tue, 28 Mar 2006 20:10:18 GMT (envelope-from gnats) Date: Tue, 28 Mar 2006 20:10:18 GMT Message-Id: <200603282010.k2SKAI1Y012836@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: John Baldwin Cc: Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:10:19 -0000 The following reply was made to PR kern/94939; it has been noted by GNATS. From: John Baldwin To: Nate Lawson Cc: bug-followup@freebsd.org, dodell@ixsystems.com Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades Date: Tue, 28 Mar 2006 14:57:42 -0500 On Tuesday 28 March 2006 14:32, Nate Lawson wrote: > John Baldwin wrote: > > On Tuesday 28 March 2006 14:08, Nate Lawson wrote: > >> >>> > >> 4.7.3.6 Reset Register > >> The optional ACPI reset mechanism specifies a standard mechanism that > >> provides a complete system reset. When implemented, this mechanism must > >> reset the entire system. This includes processors, core logic, all > >> buses, and all peripherals. From an OSPM perspective, asserting the > >> reset mechanism is the logical equivalent to power cycling the machine. > >> Upon gaining control after a reset, OSPM will perform actions in > >> like manner to a cold boot. > >> ... > >> The system must reset immediately following the write to this register. > >> OSPM assumes that the processor will not execute beyond the write > >> instruction. OSPM should execute spin loops on the CPUs in the system > >> following a write to this register. > >> >>> > >> > >> So I'm ok with the patch being committed if no other tasks need to > >> happen after this shutdown handler is called. Also, all APs should be > >> stopped before this happens and it should only occur once on the BSP. > > > > Does the reset mechanism require that ACPI be "functioning"? That is, > > does it have to happen before the call to AcpiTerminate() or can it > > happen afterwards? If it can happen afterwards, it should probably be > > moved to be part of cpu_reset_real(). > > It *probably* works without acpi enabled because on x86 at least, it's > just a write to the SMM io port, which triggers an SMI and the handler > resets the machine. SMM is present whether in legacy mode or acpi mode. > However, I don't want to put acpi-specific resets in cpu_reset_real() > because then acpi is mandatory for linking the kernel. Let's just try > it in the place the patch puts it for now and see if there are any problems. Well, the place it happens now the APs aren't spinning yet, and it won't work for the 'reset' command in ddb (though that is perhaps less important). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org