From nobody@FreeBSD.org  Sat Mar 25 23:05:32 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6E3D516A401
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 25 Mar 2006 23:05:32 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2EF4E43D46
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 25 Mar 2006 23:05:32 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k2PN5Wtq068905
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 25 Mar 2006 23:05:32 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k2PN5Vg2068904;
	Sat, 25 Mar 2006 23:05:31 GMT
	(envelope-from nobody)
Message-Id: <200603252305.k2PN5Vg2068904@www.freebsd.org>
Date: Sat, 25 Mar 2006 23:05:31 GMT
From: "Devon H. O'Dell" <dodell@iXsystems.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [acpi] [patch] reboot(8) fails on IBM / Intel blades
X-Send-Pr-Version: www-2.3

>Number:         94939
>Category:       kern
>Synopsis:       [acpi] [patch] reboot(8) fails on IBM / Intel blades
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 25 23:10:13 GMT 2006
>Closed-Date:    Mon Mar 26 20:29:43 GMT 2007
>Last-Modified:  Mon Mar 26 20:29:43 GMT 2007
>Originator:     Devon H. O'Dell
>Release:        6.1-PRERELEASE
>Organization:
iXsystems
>Environment:
FreeBSD maria.fdev.iXsystems.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #8: Sat Mar 25 10:53:25 PST 2006     root@maria.fdev.iXsystems.com:/usr/obj/usr/src/sys/BLADE  amd64

>Description:
Intel SBX82 blades do not have a keyboard controller and thus
do not reset by traditional means. This also has the implication
that they sit there and do nothing after running reboot(8).

These blades rely on ACPI for rebooting, as discussed in the
ACPI specification 4.7.3.6 (PDF page 95). Without this
support, it is impossible to reboot these blades from within
the operating system (without doing evil things to the CPU).
>How-To-Repeat:
Obtain root privileges on a blade. Run reboot(8).
>Fix:
I (very briefly) spoke with njl@ on this issue in an email.
He suggested putting it somewhere else, though I'm sort of 
curious as to where it should go otherwise. The patch is 
in acpi_shutdown_final, which is supposed to execute after 
everything, since it is used to halt the system. I'd be 
happy to put this in its own function and use 
EVENTHANDLER(9) to run it later, if possible.

The patch is attached here, and is also available at
http://www.sitetronics.com/~dodell/acpi.diff

Index: sys/dev/acpica/acpi.c
===================================================================
RCS file: /home/dodell/cvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.219
diff -u -r1.219 acpi.c
--- sys/dev/acpica/acpi.c       7 Nov 2005 21:52:06 -0000       1.219
+++ sys/dev/acpica/acpi.c       25 Mar 2006 23:04:11 -0000
@@ -48,9 +48,14 @@
 #include <sys/sbuf.h>
 #include <sys/smp.h>

+#include <vm/vm.h>
+#include <vm/pmap.h>
+
 #include <machine/clock.h>
 #include <machine/resource.h>
 #include <machine/bus.h>
+#include <machine/cpufunc.h>
+#include <machine/pci_cfgreg.h>
 #include <sys/rman.h>
 #include <isa/isavar.h>
 #include <isa/pnpvar.h>
@@ -1636,6 +1641,49 @@
            DELAY(1000000);
            printf("ACPI power-off failed - timeout\n");
        }
+    } else if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) {
+       switch (AcpiGbl_FADT->ResetRegister.AddressSpaceId) {
+       case ACPI_ADR_SPACE_SYSTEM_MEMORY:
+       {
+           char *addr;
+
+           if (AcpiGbl_FADT->ResetRegister.Address == 0)
+               panic("NULL Reset Address");
+
+           addr = pmap_mapdev(
+               (vm_offset_t)AcpiGbl_FADT->ResetRegister.Address,
+               (size_t)AcpiGbl_FADT->ResetRegister.RegisterBitWidth);
+           *addr = AcpiGbl_FADT->ResetValue;
+       }
+       break;
+       case ACPI_ADR_SPACE_SYSTEM_IO:
+       {
+           uint64_t port;
+
+           port = AcpiGbl_FADT->ResetRegister.Address;
+           outb(port, AcpiGbl_FADT->ResetValue);
+       }
+       break;
+       case ACPI_ADR_SPACE_PCI_CONFIG:
+       {
+           uint64_t gas = AcpiGbl_FADT->ResetRegister.Address;
+           int bus, device, function, offset;
+
+           bus = 0;
+            device = (gas & ACPI_GAS_DEVICE_MASK) >> ACPI_GAS_DEVICE_SHIFT;
+           function = (gas & ACPI_GAS_FUNCTION_MASK) >>
+               ACPI_GAS_FUNCTION_SHIFT;
+           offset = (gas & ACPI_GAS_OFFSET_MASK);
+
+           pci_cfgregwrite(bus, device, function, offset,
+               AcpiGbl_FADT->ResetValue, 1);
+       }
+       break;
+       default:
+           printf("I didn't match any address space types!\n");
+       }
+       DELAY(1000000);
+       printf("ACPI reboot failed - timeout\n");
     } else if (panicstr == NULL) {
        printf("Shutting down ACPI\n");
        AcpiTerminate();
Index: sys/dev/acpica/acpivar.h
===================================================================
RCS file: /home/dodell/cvs/src/sys/dev/acpica/acpivar.h,v
retrieving revision 1.100
diff -u -r1.100 acpivar.h
--- sys/dev/acpica/acpivar.h    6 Dec 2005 14:47:28 -0000       1.100
+++ sys/dev/acpica/acpivar.h    25 Mar 2006 22:25:42 -0000
@@ -426,5 +426,11 @@
 /* Use the device logging level for ktr(4). */
 #define        KTR_ACPI                KTR_DEV

+#define ACPI_GAS_DEVICE_MASK 0x0000FFFF00000000ULL
+#define ACPI_GAS_DEVICE_SHIFT 32
+#define ACPI_GAS_FUNCTION_MASK 0x00000000FFFF0000ULL
+#define ACPI_GAS_FUNCTION_SHIFT 16
+#define ACPI_GAS_OFFSET_MASK 0x000000000000FFFFULL
+
 #endif /* _KERNEL */
 #endif /* !_ACPIVAR_H_ */

>Release-Note:
>Audit-Trail:

From: John Baldwin <jhb@freebsd.org>
To: bug-followup@freebsd.org, dodell@ixsystems.com
Cc: njl@frebsd.org
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Tue, 28 Mar 2006 10:55:40 -0500

 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).
 
 -- 
 John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

From: Nate Lawson <nate@root.org>
To: John Baldwin <jhb@freebsd.org>
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 11:08:02 -0800

 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.
  >>>
 
 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.
 
 -- 
 Nate

From: John Baldwin <jhb@freebsd.org>
To: Nate Lawson <nate@root.org>
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:22:56 -0500

 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().
 
 -- 
 John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

From: Nate Lawson <nate@root.org>
To: John Baldwin <jhb@freebsd.org>
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 11:32:14 -0800

 > 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.
 
 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.
 
 -- 
 Nate

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

 > 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

From: John Baldwin <jhb@freebsd.org>
To: Nate Lawson <nate@root.org>
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

 > 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 <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

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 12:21:00 -0800

 ------=_Part_3258_17872550.1143577260091
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 > 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.
 
 Please see http://www.sitetronics.com/~dodell/acpi2.diff (also
 attached). This addresses this issue and significantly reduces the
 size of the diff :)
 
 --Devon
 
 ------=_Part_3258_17872550.1143577260091
 Content-Type: application/octet-stream; name="acpi2.diff"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="acpi2.diff"
 
 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGkuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9k
 b2RlbGwvY3ZzL3NyYy9zeXMvZGV2L2FjcGljYS9hY3BpLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9u
 IDEuMjE5CmRpZmYgLXUgLXIxLjIxOSBhY3BpLmMKLS0tIHN5cy9kZXYvYWNwaWNhL2FjcGkuYwk3
 IE5vdiAyMDA1IDIxOjUyOjA2IC0wMDAwCTEuMjE5CisrKyBzeXMvZGV2L2FjcGljYS9hY3BpLmMJ
 MjggTWFyIDIwMDYgMjA6MDY6MTUgLTAwMDAKQEAgLTE2MzYsNiArMTYzNiwxNiBAQAogCSAgICBE
 RUxBWSgxMDAwMDAwKTsKIAkgICAgcHJpbnRmKCJBQ1BJIHBvd2VyLW9mZiBmYWlsZWQgLSB0aW1l
 b3V0XG4iKTsKIAl9CisgICAgfSBlbHNlIGlmICgoaG93dG8gJiBSQl9BVVRPQk9PVCkgIT0gMCAm
 JiBBY3BpR2JsX0ZBRFQtPlJlc2V0UmVnU3VwKSB7CisJc3RhdHVzID0gQWNwaUh3TG93TGV2ZWxX
 cml0ZSg4LCBBY3BpR2JsX0ZBRFQtPlJlc2V0VmFsdWUsCisJICAgIEFjcGlHYmxfRkFEVC0+UmVz
 ZXRSZWdpc3Rlcik7CisKKwlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1cykpIHsKKwkgICAgcHJpbnRm
 KCJBQ1BJIHJlc2V0IGZhaWxlZCAtICVzXG4iLCBBY3BpRm9ybWF0RXhjZXB0aW9uKHN0YXR1cykp
 OworCX0gZWxzZSB7CisJICAgIERFTEFZKDEwMDAwMDApOworCSAgICBwcmludGYoIkFDUEkgcmVz
 ZXQgZmFpbGVkIC0gdGltZW91dFxuIik7CisJfQogICAgIH0gZWxzZSBpZiAocGFuaWNzdHIgPT0g
 TlVMTCkgewogCXByaW50ZigiU2h1dHRpbmcgZG93biBBQ1BJXG4iKTsKIAlBY3BpVGVybWluYXRl
 KCk7Cg==
 ------=_Part_3258_17872550.1143577260091--

From: John Baldwin <jhb@freebsd.org>
To: "Devon H. O'Dell" <devon.odell@gmail.com>
Cc: "Nate Lawson" <nate@root.org>, bug-followup@freebsd.org
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Tue, 28 Mar 2006 15:40:36 -0500

 > Please see http://www.sitetronics.com/~dodell/acpi2.diff (also
 > attached). This addresses this issue and significantly reduces the
 > size of the diff :)
 
 Maybe it should use AcpiGbl_FADT->ResetRegister.RegisterBitWidth rather
 than hardcoding 8?
 
 -- 
 John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: "John Baldwin" <jhb@freebsd.org>
Cc: "Nate Lawson" <nate@root.org>, bug-followup@freebsd.org
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Tue, 28 Mar 2006 13:14:18 -0800

 *bangs head on keyboard*
 
 Sorry for the flood of stuff.
 
 And now, acpi4.diff which actually includes the correct header file,
 too. *sighs* sorry about that. I'm not going to attach the diff here
 because gmail seems to find it necessary to base64-encode it and
 transfer it as application/octet-stream :(
 
 http://www.sitetronics.com/~dodell/acpi4.diff
 
 --Devon

From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: "John Baldwin" <jhb@freebsd.org>
Cc: "Nate Lawson" <nate@root.org>, bug-followup@freebsd.org
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Tue, 28 Mar 2006 12:52:56 -0800

 ------=_Part_3734_24539965.1143579176761
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 > Maybe it should use AcpiGbl_FADT->ResetRegister.RegisterBitWidth rather
 > than hardcoding 8?
 
 You're right, I should have used that. It will always be 8 as is
 stated in the specification, but that's a better idea. I shouldn't
 have missed that. Thanks!
 
 http://www.sitetronics.com/~dodell/acpi3.diff -- attached for audit
 trail convenience.
 
 --Devon
 
 ------=_Part_3734_24539965.1143579176761
 Content-Type: application/octet-stream; name=acpi3.diff
 Content-Transfer-Encoding: 7bit
 X-Attachment-Id: 0.1
 Content-Disposition: attachment; filename="acpi3.diff"
 
 Index: sys/dev/acpica/acpi.c
 ===================================================================
 RCS file: /home/dodell/cvs/src/sys/dev/acpica/acpi.c,v
 retrieving revision 1.219
 diff -u -r1.219 acpi.c
 --- sys/dev/acpica/acpi.c	7 Nov 2005 21:52:06 -0000	1.219
 +++ sys/dev/acpica/acpi.c	28 Mar 2006 20:51:39 -0000
 @@ -1636,6 +1636,17 @@
  	    DELAY(1000000);
  	    printf("ACPI power-off failed - timeout\n");
  	}
 +    } else if ((howto & RB_AUTOBOOT) != 0 && AcpiGbl_FADT->ResetRegSup) {
 +	status = AcpiHwLowLevelWrite(
 +	    AcpiGbl_FADT->ResetRegister.RegisterBitWidth,
 +	    AcpiGbl_FADT->ResetValue, AcpiGbl_FADT->ResetRegister);
 +
 +	if (ACPI_FAILURE(status)) {
 +	    printf("ACPI reset failed - %s\n", AcpiFormatException(status));
 +	} else {
 +	    DELAY(1000000);
 +	    printf("ACPI reset failed - timeout\n");
 +	}
      } else if (panicstr == NULL) {
  	printf("Shutting down ACPI\n");
  	AcpiTerminate();
 
 ------=_Part_3734_24539965.1143579176761--

From: Nate Lawson <nate@root.org>
To: "Devon H. O'Dell" <devon.odell@gmail.com>
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 22:49:31 -0800

 Committed with some minor fixes, thanks.  We'll MFC after it's shown not 
 to harm reboots on other systems.
 
 -- 
 Nate

From: "Devon H. O'Dell" <dodell@iXsystems.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:22:35 -0800

 > 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.
 
 --Devon
 
 > -- 
 > Nate

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

 > 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.
 
 -- 
 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org

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

 > 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.
 
 I'm not near a BSD box today.  Is there a simple, MI way of hooking 
 there that doesn't require ACPI compiled into the kernel?  If it's a 
 simple matter of moving it to a different shutdown handler or adding a 
 way for acpi to conditionally override cpu_reset_real, that's ok with 
 me.  I don't want acpi being partially merged into the main kernel.
 
 -- 
 Nate

From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: "Nate Lawson" <nate@root.org>, "John Baldwin" <jhb@freebsd.org>, 
	bug-followup@freebsd.org
Cc:  
Subject: Re: kern/94939: [acpi] [patch] reboot(8) fails on IBM / Intel blades
Date: Thu, 30 Mar 2006 10:31:05 -0800

 > I'm not near a BSD box today.  Is there a simple, MI way of hooking
 > there that doesn't require ACPI compiled into the kernel?  If it's a
 > simple matter of moving it to a different shutdown handler or adding a
 > way for acpi to conditionally override cpu_reset_real, that's ok with
 > me.  I don't want acpi being partially merged into the main kernel.
 
 I can move this to its own event handler that will be executed later on.
 
 > --
 > Nate

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

 > I'm not near a BSD box today.  Is there a simple, MI way of hooking 
 > there that doesn't require ACPI compiled into the kernel?  If it's a 
 > simple matter of moving it to a different shutdown handler or adding a 
 > way for acpi to conditionally override cpu_reset_real, that's ok with 
 > me.  I don't want acpi being partially merged into the main kernel.
 
 Not currently.
 
 -- 
 John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Sun Mar 18 22:00:21 UTC 2007 
State-Changed-Why:  
Did this code ever get committed? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94939 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Mon Mar 26 20:29:41 UTC 2007 
State-Changed-Why:  
feedback timeout, please notify us when you have additional feedback! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94939 
>Unformatted:
