kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades

[John Baldwin]

The following reply was made to PR kern/94939; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: "Devon H. O'Dell" <dodell at ixsystems.com>
Cc: Nate Lawson <nate at root.org>, bug-followup at freebsd.org
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Thu, 30 Mar 2006 08:03:23 -0500

 On Tuesday 28 March 2006 02:22 pm, Devon H. O'Dell wrote:
 > On Tue, Mar 28, 2006 at 11:08:02AM -0800, Nate Lawson wrote:
 > > John Baldwin wrote:
 > > > Nate,
 > > >
 > > > I'm curious where you think this code should go if not here?  I'd
 > > > imagine we don't want to do this after AcpiTerminate() since perhaps
 > > > the specified register may no longer be available (I might be wrong
 > > > though, I haven't checked the spec).
 > >
 > > I don't have a specific idea since I didn't look at it closely.  I think
 > > there might be some requirements of writes to the reset register
 > > (delays, expectation of chipset configuration, order with other shutdown
 > > tasks).  Here are the requirements from the spec:
 > >
 > >
 > > 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.
 >
 > My interpretation of this is ``don't do anything else after
 > the write to the register, because you can't expect to do
 > it.'' Since they say that the system ``must reset immediately
 > following the write'', it seems that this is implemented in
 > hardware, and we can't assume that we will be able to do
 > anything afterwards, anyway.
 >
 > > 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.
 >
 > I was curious if anything happens after this handler is
 > called -- if there is, we definitely need to move it back
 > to later in the process. Again, I put the code here because it
 > looked to me like the procedure already assumed nothing else
 > is happening, but it sounds like there are other procedures
 > that are in the call queue after this one.
 
 It really should be much later I think: in cpu_reset_real() as that
 is the only place that you know that the APs are stopped.
 
 =2D-=20
 John Baldwin <jhb at FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org