From uspoerlein@gmail.com  Thu May 15 16:06:49 2008
Return-Path: <uspoerlein@gmail.com>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 3B693106567B
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 15 May 2008 16:06:49 +0000 (UTC)
	(envelope-from uspoerlein@gmail.com)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190])
	by mx1.freebsd.org (Postfix) with ESMTP id ABD3D8FC28
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 15 May 2008 16:06:48 +0000 (UTC)
	(envelope-from uspoerlein@gmail.com)
Received: by nf-out-0910.google.com with SMTP id h3so243987nfh.33
        for <FreeBSD-gnats-submit@freebsd.org>; Thu, 15 May 2008 09:06:47 -0700 (PDT)
Received: by 10.124.66.14 with SMTP id o14mr1479813mka.176.1210867606555;
        Thu, 15 May 2008 09:06:46 -0700 (PDT)
Received: from acme.spoerlein.net ( [217.172.44.86])
        by mx.google.com with ESMTPS id 13sm4932051fks.12.2008.05.15.09.06.42
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 15 May 2008 09:06:42 -0700 (PDT)
Received: from coyote.spoerlein.net (e180141163.adsl.alicedsl.de [85.180.141.163])
	by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id m4FG6d4U094439
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 15 May 2008 18:06:40 +0200 (CEST)
	(envelope-from uspoerlein@gmail.com)
Received: from coyote.spoerlein.net (localhost [127.0.0.1])
	by coyote.spoerlein.net (8.14.2/8.14.2) with ESMTP id m4FG6dVP061321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 May 2008 18:06:39 +0200 (CEST)
	(envelope-from uqs@coyote.spoerlein.net)
Received: (from uqs@localhost)
	by coyote.spoerlein.net (8.14.2/8.14.2/Submit) id m4FG6ckJ061320;
	Thu, 15 May 2008 18:06:38 +0200 (CEST)
	(envelope-from uqs)
Message-Id: <200805151606.m4FG6ckJ061320@coyote.spoerlein.net>
Date: Thu, 15 May 2008 18:06:38 +0200 (CEST)
From: Ulrich Spörlein <uspoerlein@gmail.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc: rpaulo@freebsd.org, njl@freebsd.org, gavin@freebsd.org
Subject: REGRESSION: acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP
X-Send-Pr-Version: 3.113
X-GNATS-Notify: rpaulo@freebsd.org

>Number:         123705
>Category:       kern
>Synopsis:       [acpi] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    rpaulo
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 15 16:10:00 UTC 2008
>Closed-Date:    Tue Jun 10 14:10:11 UTC 2008
>Last-Modified:  Fri Nov 12 20:52:07 UTC 2010
>Originator:     Ulrich Spoerlein
>Release:        FreeBSD 6.3-STABLE i386
>Organization:
>Environment:
>Description:
The MFC of rev. 1.67 to RELENG_6 leads to a panic upon boot. See 
http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042439.html
for an unsuccessful try.

Here are ACPI dumps:
http://www.spoerlein.net/pub/X7DBP.asl
http://www.spoerlein.net/pub/X7DBP.dsdt

>How-To-Repeat:
You would need the Hardware+BIOS version in question. I can test patches for the next
7-10 days only.

>Fix:

Deactivate _OSC :/

--- acpi.diff begins here ---
Index: sys/dev/acpica/acpi_cpu.c
===================================================================
RCS file: /data/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.57.2.8
diff -u -r1.57.2.8 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c	17 Mar 2008 19:57:21 -0000	1.57.2.8
+++ sys/dev/acpica/acpi_cpu.c	15 May 2008 15:21:13 -0000
@@ -377,7 +377,7 @@
 	arg[3].Buffer.Length = sizeof(cap_set);	/* Capabilities buffer */
 	arg[3].Buffer.Pointer = (uint8_t *)cap_set;
 	cap_set[0] = 0;
-	AcpiEvaluateObject(sc->cpu_handle, "_OSC", &arglist, NULL);
+	//AcpiEvaluateObject(sc->cpu_handle, "_OSC", &arglist, NULL);
     }
 
     /* Probe for Cx state support. */
--- acpi.diff ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Thu May 15 18:22:52 UTC 2008 
Responsible-Changed-Why:  
Over to maintainers.  Submitter has determined that rpaulo's MFC 
of src/sys/dev/acpica/acpi_cpu.c 1.67 is responsible for causing 
6.3-RELEAASE to panic on boot.  He can only test patches for the 
next 7-10 days. 

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

Date: Fri, 16 May 2008 15:22:43 +0100 (WEST)
From: Rui Paulo <rpaulo@fnop.net>
 
 Could you please test this patch? Thanks!
 
 Index: acpi_cpu.c
 =====================================================================
 RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
 retrieving revision 1.72
 diff -u -p -r1.72 acpi_cpu.c
 --- acpi_cpu.c	12 Apr 2008 12:06:00 -0000	1.72
 +++ acpi_cpu.c	16 May 2008 14:15:40 -0000
 @@ -276,9 +276,10 @@ acpi_cpu_attach(device_t dev)
      uint32_t		   cap_set[3];
 
      /* UUID needed by _OSC evaluation */
 -    static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
 -				       0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
 -				       0x58, 0x71, 0x39, 0x53 };
 +    static uint8_t cpu_oscuuid[16] = { 0x5B, 0x4D, 0xDB, 0x33, 0xF7,
 +				       0x1F, 0x1C, 0x40, 0x96, 0x57,
 +				       0x74, 0x41, 0xC0, 0x3D, 0xD7,
 +				       0x66 };
 
      ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
 
 
 --
 Rui Paulo
State-Changed-From-To: open->feedback 
State-Changed-By: rpaulo 
State-Changed-When: Fri May 16 22:26:28 UTC 2008 
State-Changed-Why:  
feedback requested. 


Responsible-Changed-From-To: freebsd-acpi->rpaulo 
Responsible-Changed-By: rpaulo 
Responsible-Changed-When: Fri May 16 22:26:28 UTC 2008 
Responsible-Changed-Why:  
My problem. 

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

From: Ulrich Spoerlein <uspoerlein@gmail.com>
To: rpaulo@FreeBSD.org
Cc: freebsd-acpi@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/123705: [acpi_cpu] [regression] acpi_cpu.c rev 1.57.2.4
	broke booting on SuperMicro X7DBP
Date: Sun, 18 May 2008 13:06:10 +0200

 Hi,
 
 only tested the patch on this one machine, no more panics, although
 the _OSC evaluation itself fails:
 
 cpu0: <ACPI CPU> on acpi0
     ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc871e660), AE_AML_OPERAND_TYPE
 cpu0: switching to generic Cx mode
 acpi_throttle0: <ACPI CPU Throttling> on cpu0
 acpi_throttle0: P_CNT from P_BLK 0x1010
 
 Thanks!
 Ulrich Spoerlein

From: "Ulrich Spoerlein" <uspoerlein@gmail.com>
To: bug-followup@FreeBSD.org
Cc: "Rui Paulo" <rpaulo@fnop.net>
Subject: Re: kern/123705: [acpi] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP
Date: Mon, 9 Jun 2008 15:16:54 +0200

 Hi,
 
 I managed to update the system to the latest BIOS version 2.0b which
 seems to have solved the ACPI problem. Sadly now the 3Ware controller
 BIOS is no longer started and I'm unable to boot the operating system.
 Therefore, I cannot tell you for sure, if the _OSC evaluation is
 really working (or if I did boot a patched kernel, not a vanilla one).
 
 Cheers,
 Uli
 

From: Rui Paulo <rpaulo@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/123705: [acpi] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP
Date: Mon, 9 Jun 2008 14:28:43 +0100

 On Mon, Jun 09, 2008 at 03:16:54PM +0200, Ulrich Spoerlein wrote:
 > Hi,
 > 
 > I managed to update the system to the latest BIOS version 2.0b which
 > seems to have solved the ACPI problem. Sadly now the 3Ware controller
 > BIOS is no longer started and I'm unable to boot the operating system.
 > Therefore, I cannot tell you for sure, if the _OSC evaluation is
 > really working (or if I did boot a patched kernel, not a vanilla one).
 
 Hmm, that's bad. Perhaps you can update the 3ware firmware too?
 
 -- 
 Rui Paulo
 

From: Ulrich Spoerlein <uspoerlein@gmail.com>
To: bug-followup@FreeBSD.org
Cc: rpaulo@FreeBSD.org
Subject: Re: kern/123705: [acpi] [regression] acpi/cpu.c rev 1.57.2.4 broke
	booting on SuperMicro X7DBP
Date: Tue, 10 Jun 2008 12:08:53 +0200

 I hope this GNATS followup makes it through ...
 
 I managed to get the older BIOS Version 2.0a which also solves the ACPI
 problem and manages to successfully boot the 3Ware controller.
 
 So this is a plain BIOS problem. I'm not sure if this warrants a
 blacklisting of the version 1.2. Version 2.0 boots successfully on an
 unpatched RELENG_6 kernel from mid-may.
 
 To people using these boards with 9550 3Ware controllers: Don't update
 to BIOS 2.0b!
 
 Cheers,
 Ulrich Spoerlein

From: Rui Paulo <rpaulo@FreeBSD.org>
To: Ulrich Spoerlein <uspoerlein@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/123705: [acpi] [regression] acpi/cpu.c rev 1.57.2.4 broke
	booting on SuperMicro X7DBP
Date: Tue, 10 Jun 2008 12:18:49 +0100

 On Tue, Jun 10, 2008 at 12:08:53PM +0200, Ulrich Spoerlein wrote:
 > I hope this GNATS followup makes it through ...
 > 
 > I managed to get the older BIOS Version 2.0a which also solves the ACPI
 > problem and manages to successfully boot the 3Ware controller.
 > 
 > So this is a plain BIOS problem. I'm not sure if this warrants a
 > blacklisting of the version 1.2. Version 2.0 boots successfully on an
 > unpatched RELENG_6 kernel from mid-may.
 > 
 > To people using these boards with 9550 3Ware controllers: Don't update
 > to BIOS 2.0b!
 
 Can you get me an acpidump of your current BIOS?
 
 Regards,
 -- 
 Rui Paulo
State-Changed-From-To: feedback->closed 
State-Changed-By: rpaulo 
State-Changed-When: Tue Jun 10 14:08:52 UTC 2008 
State-Changed-Why:  
Hardware bug. Updating to BIOS version > 2.0a solves the issue. 
Although, note that BIOS version 2.0b introduces some problems, namely 
with 3ware controllers. 

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

From: Rui Paulo <rpaulo@FreeBSD.org>
To: Ulrich Spoerlein <uspoerlein@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/123705: [acpi] [regression] acpi/cpu.c rev 1.57.2.4 broke
	booting on SuperMicro X7DBP
Date: Tue, 10 Jun 2008 15:06:42 +0100

 On Tue, Jun 10, 2008 at 02:00:38PM +0200, Ulrich Spoerlein wrote:
 > On Tue, 10.06.2008 at 12:18:49 +0100, Rui Paulo wrote:
 > > On Tue, Jun 10, 2008 at 12:08:53PM +0200, Ulrich Spoerlein wrote:
 > > > I hope this GNATS followup makes it through ...
 > > > 
 > > > I managed to get the older BIOS Version 2.0a which also solves the ACPI
 > > > problem and manages to successfully boot the 3Ware controller.
 > > > 
 > > > So this is a plain BIOS problem. I'm not sure if this warrants a
 > > > blacklisting of the version 1.2. Version 2.0 boots successfully on an
 > > > unpatched RELENG_6 kernel from mid-may.
 > > > 
 > > > To people using these boards with 9550 3Ware controllers: Don't update
 > > > to BIOS 2.0b!
 > > 
 > > Can you get me an acpidump of your current BIOS?
 > 
 > Attached.
 
 WRT to ACPI there is no visible change and the _OSC method is still present.
 So, I'm going to mark this as a manufacturer bug and close the PR.
 
 Thanks for all your time and patience,
 -- 
 Rui Paulo
>Unformatted:
