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

[Devon H. O'Dell]

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

From: "Devon H. O'Dell" <devon.odell at gmail.com>
To: "Nate Lawson" <nate at root.org>
Cc: "John Baldwin" <jhb at freebsd.org>, bug-followup at 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