Date: Tue, 28 Mar 2006 20:00:58 GMT From: "Devon H. O'Dell" <devon.odell@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades Message-ID: <200603282000.k2SK0wBv012473@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/94939; it has been noted by GNATS.
From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: "Nate Lawson" <nate@root.org>
Cc: "John Baldwin" <jhb@freebsd.org>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603282000.k2SK0wBv012473>