From owner-freebsd-bugs@FreeBSD.ORG Tue Mar 28 20:00:58 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 B696616A400 for ; Tue, 28 Mar 2006 20:00:58 +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 4D66743D73 for ; Tue, 28 Mar 2006 20:00:58 +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 k2SK0wfo012474 for ; Tue, 28 Mar 2006 20:00:58 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2SK0wBv012473; Tue, 28 Mar 2006 20:00:58 GMT (envelope-from gnats) Date: Tue, 28 Mar 2006 20:00:58 GMT Message-Id: <200603282000.k2SK0wBv012473@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Devon H. O'Dell" 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: "Devon H. O'Dell" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:00:58 -0000 The following reply was made to PR kern/94939; it has been noted by GNATS. From: "Devon H. O'Dell" To: "Nate Lawson" Cc: "John Baldwin" , bug-followup@freebsd.org Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades Date: Tue, 28 Mar 2006 11:52:00 -0800 MX1 hates me for some reason. On Tue, Mar 28, 2006 at 11:32:14AM -0800, 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 mu= st > >> 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 proble= ms. Ok. What I was thinking was to save the AcpiGBL_FADT->{$FOO} into some local kernel structure and then to put it into cpu_reset_real(). I suppose this would mean that I would have to then manually parse the GAS, which, as you outline below, is an outstanding issue. > The patch has some other major problems that should be addressed before > committing. It should not manually be parsing the GAS and mapping > memory etc. Instead, it should just use AcpiHwLowLevelWrite(): > > ACPI_STATUS > AcpiHwLowLevelWrite ( > UINT32 Width, > UINT32 Value, > ACPI_GENERIC_ADDRESS *Reg); > > Width should be 8, value should be the reset value in the FADT, and Reg > should be the FADT GAS struct. AHA! I figured there was some function for this, but I kept looking for something that took an ACPI_GENERIC_ADDRESS and never found it. I'll rework the patch to use this procedure instead. I sent a couple other mails but they seem to have been eaten by some network restructuring that seems to have gone unnoticed for several months :\. --Devon > -- > Nate