From nobody@FreeBSD.org  Wed Mar  1 01:13:01 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 A2A5C16A420
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  1 Mar 2006 01:13:01 +0000 (GMT)
	(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 68B9143D45
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  1 Mar 2006 01:13:01 +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 k211D0Qn024393
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 1 Mar 2006 01:13:01 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k211D0bL024392;
	Wed, 1 Mar 2006 01:13:00 GMT
	(envelope-from nobody)
Message-Id: <200603010113.k211D0bL024392@www.freebsd.org>
Date: Wed, 1 Mar 2006 01:13:00 GMT
From: Masayuki FUKUI <fukui.FreeBSD@fanet.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [panic] [patch] ACPI Panic with some ACPI 2.0 PC & cannot boot
X-Send-Pr-Version: www-2.3

>Number:         93963
>Category:       i386
>Synopsis:       [panic] [patch] ACPI Panic with some ACPI 2.0 PC & cannot boot
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    linimon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 01 01:20:04 GMT 2006
>Closed-Date:    Mon Sep 04 16:30:40 GMT 2006
>Last-Modified:  Mon Sep 04 16:30:40 GMT 2006
>Originator:     Masayuki FUKUI
>Release:        FreeBSD 5.4-RELEASE-p10
>Organization:
>Environment:
PC: Fujitsu-Siemens Celsius N440 [Pentium4 670 (3.8GHz) / 3GB Memory]
OS: FreeBSD 6.1-BETA1 / FreeBSD 5.5-BETA1 / FreeBSD 5.4-RELEASE-p10
>Description:
FreeBSD cannot be booted with some ACPI 2.0 PC.
The kernel panic occurs with the initialization of ACPI.

Cause:
In some ACPI 2.0 PC, XSDT is NULL. (RSDT is available.)
Therefore, FreeBSD traces XSDT (is NULL) and falls into the panic.

>How-To-Repeat:
Trt to boot FreeBSD 6.1-BETA1 (ACPI enable) on Fujitsu-Siemens Celsius N440.

>Fix:
I don't know how to fix rightly.
But I rebuild 5.4-RELEASE-p10 kernel with following patch, and it works fine.

I hope for fixing the probrem as soon as possible.


--- sys/contrib/dev/acpica/tbconvrt.c.orig	Sun Dec 19 13:06:14 2004
+++ sys/contrib/dev/acpica/tbconvrt.c	Wed Feb  8 22:48:21 2006
@@ -149,7 +149,7 @@
     ACPI_FUNCTION_ENTRY ();
 
 
-    if (RSDP->Revision < 2)
+    if (RSDP->Revision < 2 || !RSDP->XsdtPhysicalAddress)
     {
         PointerSize = sizeof (UINT32);
     }
@@ -214,7 +214,7 @@
 
     for (i = 0; i < AcpiGbl_RsdtTableCount; i++)
     {
-        if (AcpiGbl_RSDP->Revision < 2)
+        if (AcpiGbl_RSDP->Revision < 2 || !AcpiGbl_RSDP->XsdtPhysicalAddress)
         {
             ACPI_STORE_ADDRESS (NewTable->TableOffsetEntry[i],
                 (ACPI_CAST_PTR (RSDT_DESCRIPTOR_REV1, TableInfo->Pointer))->TableOffsetEntry[i]);
@@ -637,7 +637,7 @@
 
     AcpiGbl_CommonFACS.GlobalLock = &(AcpiGbl_FACS->GlobalLock);
 
-    if ((AcpiGbl_RSDP->Revision < 2) ||
+    if ((AcpiGbl_RSDP->Revision < 2) || (!AcpiGbl_RSDP->XsdtPhysicalAddress) ||
         (AcpiGbl_FACS->Length < 32)  ||
         (!(ACPI_GET_ADDRESS (AcpiGbl_FACS->XFirmwareWakingVector))))
     {
--- sys/contrib/dev/acpica/tbrsdt.c.orig	Sun Dec 19 13:06:14 2004
+++ sys/contrib/dev/acpica/tbrsdt.c	Wed Feb  8 23:33:27 2006
@@ -259,7 +259,7 @@
      * For RSDP revision 0 or 1, we use the RSDT.
      * For RSDP revision 2 (and above), we use the XSDT
      */
-    if (AcpiGbl_RSDP->Revision < 2)
+    if (AcpiGbl_RSDP->Revision < 2 || !AcpiGbl_RSDP->XsdtPhysicalAddress)
     {
         OutAddress->Pointer.Value = AcpiGbl_RSDP->RsdtPhysicalAddress;
     }
@@ -296,7 +296,7 @@
      * For RSDP revision 0 or 1, we use the RSDT.
      * For RSDP revision 2 and above, we use the XSDT
      */
-    if (AcpiGbl_RSDP->Revision < 2)
+    if (AcpiGbl_RSDP->Revision < 2 || !AcpiGbl_RSDP->XsdtPhysicalAddress)
     {
         NoMatch = ACPI_STRNCMP ((char *) TablePtr, RSDT_SIG,
                         sizeof (RSDT_SIG) -1);
@@ -320,7 +320,7 @@
             AcpiGbl_RSDP->RsdtPhysicalAddress,
             (void *) (ACPI_NATIVE_UINT) AcpiGbl_RSDP->RsdtPhysicalAddress));
 
-        if (AcpiGbl_RSDP->Revision < 2)
+        if (AcpiGbl_RSDP->Revision < 2 || !AcpiGbl_RSDP->XsdtPhysicalAddress)
         {
             ACPI_REPORT_ERROR (("Looking for RSDT (RSDP->Rev < 2)\n"))
         }
--- sys/contrib/dev/acpica/tbxfroot.c.orig	Sun Dec 19 13:06:14 2004
+++ sys/contrib/dev/acpica/tbxfroot.c	Wed Feb  8 22:47:32 2006
@@ -362,7 +362,7 @@
     {
         /* Get the next table pointer, handle RSDT vs. XSDT */
 
-        if (AcpiGbl_RSDP->Revision < 2)
+        if (AcpiGbl_RSDP->Revision < 2 || !AcpiGbl_RSDP->XsdtPhysicalAddress)
         {
             Address.Pointer.Value = (ACPI_CAST_PTR (
                 RSDT_DESCRIPTOR, RsdtInfo->Pointer))->TableOffsetEntry[i];
@@ -514,7 +514,7 @@
 
         /* Signature matches, check the appropriate checksum */
 
-        if (((RSDP_DESCRIPTOR *) MemRover)->Revision < 2)
+        if (((RSDP_DESCRIPTOR *) MemRover)->Revision < 2 || !(((RSDP_DESCRIPTOR *) MemRover)->XsdtPhysicalAddress))
         {
             /* ACPI version 1.0 */
 
--- sys/i386/acpica/madt.c.orig	Mon Feb 28 06:28:18 2005
+++ sys/i386/acpica/madt.c	Wed Feb  8 23:30:14 2006
@@ -223,7 +223,7 @@
 	 * We map the XSDT and RSDT at page 1 in the crashdump area.
 	 * Page 0 is used to map in the headers of candidate ACPI tables.
 	 */
-	if (rsdp->Revision >= 2) {
+	if (rsdp->Revision >= 2 && rsdp->XsdtPhysicalAddress) {
 		/*
 		 * AcpiOsGetRootPointer only verifies the checksum for
 		 * the version 1.0 portion of the RSDP.  Version 2.0 has

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-acpi 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Mar 21 00:31:09 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=93963 

From: Nate Lawson <nate@root.org>
To: fukui.FreeBSD@fanet.net
Cc: freebsd-acpi@freebsd.org, bug-followup@freebsd.org
Subject: Re: i386/93963: [panic] [patch] ACPI Panic with some ACPI 2.0 PC
 &	cannot boot
Date: Tue, 21 Mar 2006 12:24:08 -0800

 John Baldwin wrote:
 > The patch basically forces the use of ACPI 1.0 tables if the ACPI 2.0 table
 > pointer is NULL.  This is really just more BIOS brain damage.  Most of the
 > patch is to Intel's ACPI-CA code, so we need to see what they think about
 > this workaround.
 
 Fukui-san,
 
 Would you please submit the output of acpidump -t to the PR?  This would 
 help us understand the RSDT and XSDT on your machine.
 
 -- 
 Nate

From: Nate Lawson <nate@root.org>
To: fukui.FreeBSD@fanet.net
Cc: freebsd-acpi@freebsd.org, bug-followup@freebsd.org
Subject: Re: i386/93963: [panic] [patch] ACPI Panic with some ACPI 2.0 PC
 &	cannot boot
Date: Tue, 21 Mar 2006 13:12:00 -0800

 I contacted Robert Moore at Intel and he informed us this is fixed in 
 the 200506 distro of acpi-ca.  We have an even newer version in 
 7-current, so you can test that also to be sure it fixes your problem.
 
 Unfortunately, we cannot MFC acpi-ca to 6.x until a known memory leak is 
 fixed.  We'll close this bug once 7-current works for you and we are 
 able to MFC acpi-ca.
 
 -- 
 Nate

From: Masayuki FUKUI <fukui.FreeBSD@fanet.net>
To: nate@root.org
Cc: freebsd-acpi@freebsd.org, bug-followup@freebsd.org
Subject: Re: i386/93963: [panic] [patch] ACPI Panic with some ACPI 2.0 PC &	cannot boot
Date: Mon, 27 Mar 2006 18:23:21 +0900

 >>>>> In <44206C20.1060603@root.org> 
 >>>>>	Nate Lawson <nate@root.org> wrote:
 > I contacted Robert Moore at Intel and he informed us this is fixed in 
 > the 200506 distro of acpi-ca.  We have an even newer version in 
 > 7-current, so you can test that also to be sure it fixes your problem.
 
 Thank you, Nate-san.
 I tested it, and 7-current (7.0-CURRENT-SNAP013-i386) could be booted.
 
 > Unfortunately, we cannot MFC acpi-ca to 6.x until a known memory leak is 
 > fixed.  We'll close this bug once 7-current works for you and we are 
 > able to MFC acpi-ca.
 
 I see.
 
 PS
 `acpidump -t' terminates abnormally.
 
 |# acpidump -t
 |/*
 |  RSD PTR: OEM=PTLTD, ACPI_Rev=2.0x (2)
 |        XSDT=0x00000000, length=0, cksum=0
 | */
 |acpidump: can't map address: Invalid argument

From: John Baldwin <jhb@freebsd.org>
To: freebsd-acpi@freebsd.org
Cc: Masayuki FUKUI <fukui.FreeBSD@fanet.net>, nate@root.org,
        bug-followup@freebsd.org
Subject: Re: i386/93963: [panic] [patch] ACPI Panic with some ACPI 2.0 PC =?iso-8859-1?q?=26=09cannot?= boot
Date: Mon, 27 Mar 2006 11:01:19 -0500

 On Monday 27 March 2006 04:23, Masayuki FUKUI wrote:
 > >>>>> In <44206C20.1060603@root.org> 
 > >>>>>	Nate Lawson <nate@root.org> wrote:
 > > I contacted Robert Moore at Intel and he informed us this is fixed in 
 > > the 200506 distro of acpi-ca.  We have an even newer version in 
 > > 7-current, so you can test that also to be sure it fixes your problem.
 > 
 > Thank you, Nate-san.
 > I tested it, and 7-current (7.0-CURRENT-SNAP013-i386) could be booted.
 
 I've just committed the madt patches from this PR, thanks!
 
 -- 
 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: Mon Jul 17 04:23:53 UTC 2006 
State-Changed-Why:  
To submitter: did this commit fix your problem? 


Responsible-Changed-From-To: freebsd-acpi->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jul 17 04:23:53 UTC 2006 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=93963 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Mon Sep 4 16:30:09 UTC 2006 
State-Changed-Why:  
Feedback timeout (~6 weeks). 

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