NetBSD Problem Report #43121

From jruohone@gmail.com  Sun Apr  4 21:17:40 2010
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id AA0BF63B11D
	for <gnats-bugs@gnats.netbsd.org>; Sun,  4 Apr 2010 21:17:40 +0000 (UTC)
Message-Id: <20100404201229.D5AC32A59@marx.bitnet>
Date: Sun,  4 Apr 2010 23:12:29 +0300 (EEST)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: acpidump(8) does not output all SSDT entries
X-Send-Pr-Version: 3.95

>Number:         43121
>Category:       bin
>Synopsis:       acpidump(8) does not output all SSDT entries
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    jruoho
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 04 21:20:00 +0000 2010
>Closed-Date:    
>Last-Modified:  Wed Apr 20 07:11:20 +0000 2011
>Originator:     Jukka Ruohonen
>Release:        NetBSD 5.0_STABLE
>Organization:
-
>Environment:
...

>Description:

The acpidump(8) utility has some problems dumping entries declared as
External() in the DSDT. An example from the DSDT of Dell Studio XP16:

        External (NDN3, MethodObj)    // 1 Arguments
        External (WMAB, MethodObj)    // 1 Arguments
        External (FPED, MethodObj)    // 0 Arguments
        External (GP52)
        External (NNAB, IntObj)
        External (IDAB, MethodObj)    // 0 Arguments
        External (\_PR_.CPU0._PPC)

Majority of these are not appended to the output of acpidump(8), even though
it is documented that "if any Secondary System Description Table (SSDT)
entries exist, they will also be included in the output file and
disassembly".

>How-To-Repeat:

acpidump(8), ACPI 4.0 standard, code inspection.

>Fix:

A possible patch:

  http://mail-index.netbsd.org/tech-userlevel/2008/09/16/msg001235.html

In the long-run the best solution is probably to replace acpidump(8) with a
similar utility from the Intel ACPICA reference implementation. This has
been discussed in FreeBSD "upstream":

  http://lists.freebsd.org/pipermail/freebsd-acpi/2009-June/005787.html

>Release-Note:

>Audit-Trail:
From: Christoph Egger <Christoph_Egger@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: Jukka Ruohonen <jruohonen@iki.fi>, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Sun, 04 Apr 2010 23:47:35 +0200

 > In the long-run the best solution is probably to replace acpidump(8) with a
 > similar utility from the Intel ACPICA reference implementation.

 I did that in -current month ago. acpidump(8) in -current uses iasl.

 Christoph

From: Bernd Ernesti <netbsd@lists.veego.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Mon, 5 Apr 2010 00:03:20 +0200

 On Sun, Apr 04, 2010 at 09:50:04PM +0000, Christoph Egger wrote:
 >  > In the long-run the best solution is probably to replace acpidump(8) with a
 >  > similar utility from the Intel ACPICA reference implementation.
 >  
 >  I did that in -current month ago. acpidump(8) in -current uses iasl.

 That won't help anything if it is only for -current since he is using netbsd-5
 acpidump(8) in netbsd-5 is broken to a state that it core dumps for some BIOS.

 Bernd

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Mon, 5 Apr 2010 01:22:29 +0300

 On Sun, Apr 04, 2010 at 10:05:03PM +0000, Bernd Ernesti wrote:
 >  On Sun, Apr 04, 2010 at 09:50:04PM +0000, Christoph Egger wrote:
 >  >  > In the long-run the best solution is probably to replace acpidump(8) with a
 >  >  > similar utility from the Intel ACPICA reference implementation.
 >  >  
 >  >  I did that in -current month ago. acpidump(8) in -current uses iasl.
 >  
 >  That won't help anything if it is only for -current since he is using netbsd-5
 >  acpidump(8) in netbsd-5 is broken to a state that it core dumps for some BIOS.

 This was filed for a third party. I am waiting for a confirmation that the
 "-t" flag was used with acpidump(8).

 But a pull-up request for 5.0 should be done nevertheless (a non-intrusive
 update used only for debugging).

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, jruohonen@iki.fi
Subject: re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Fri, 09 Apr 2010 15:58:26 +1000


     This was filed for a third party. I am waiting for a confirmation that the
     "-t" flag was used with acpidump(8).

 it was done with -t and a couple of weeks ago -current.

 very -current kernels can't run acpidump it seems.  it locks up hard for me.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Sat, 10 Apr 2010 09:50:09 +0300

 On Sun, Apr 04, 2010 at 09:50:04PM +0000, Christoph Egger wrote:
 >  > In the long-run the best solution is probably to replace acpidump(8) with a
 >  > similar utility from the Intel ACPICA reference implementation.
 >  
 >  I did that in -current month ago. acpidump(8) in -current uses iasl.

 It uses iasl(8) only for disassembly. Against the documentation, it is
 unable to extract multiple SSDTs. An example from ThinPad X60s:

 /*
   SSDT: Length=476, Revision=1, Checksum=32,
         OEMID=LENOVO, OEM Table ID=TP-7B, OEM Revision=0x2180,
         Creator ID=MSFT, Creator Revision=0x100000e
  */
 /*
   SSDT: Length=607, Revision=1, Checksum=89,
         OEMID=LENOVO, OEM Table ID=TP-7B, OEM Revision=0x2180,
         Creator ID=INTL, Creator Revision=0x20050513
  */
 /* 
   SSDT: Length=166, Revision=1, Checksum=255,
         OEMID=LENOVO, OEM Table ID=TP-7B, OEM Revision=0x2180,
         Creator ID=INTL, Creator Revision=0x20050513
  */
 /*
   SSDT: Length=1271, Revision=1, Checksum=42,
         OEMID=LENOVO, OEM Table ID=TP-7B, OEM Revision=0x2180,
         Creator ID=INTL, Creator Revision=0x20050513
  */
 /*
   SSDT: Length=472, Revision=1, Checksum=160,
         OEMID=LENOVO, OEM Table ID=TP-7B, OEM Revision=0x2180,
         Creator ID=INTL, Creator Revision=0x20050513
  */

 But only one of these is appended to the output of acpidump(8).

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Fri, 11 Jun 2010 02:24:23 +0300


 After talking to Gregoire Sutre, we were able to understand what the problem
 is. It is not the External() but the Load() opcode, which loads additional
 tables dynamically. Again an example from the ThinkPad X60s:

 	OperationRegion (IST0, SystemMemory,
         	DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))

 	Load (IST0, HI0)

 where the required address is conveyed in the OperationRegion declaration.

 The kernel has no problems dealing with this, but increasingly it appears
 that acpidump(8) is broken beyond repair; parsing the address from the above
 operation region requires the help of the interpreter, and even then it can
 be dangeours, given that /dev/mem is involved.

 Note also that a similar acpidump program on Linux is broken as well.

 As said, dealing with this is easy in the kernel. A possible solution would
 be to pass the data from the kernel to the userland via an ioctl or an
 equivalent mechanism. This would likely be the end of acpidump(8) as we know
 it.

 I am working towards a solution, but it is unlikely to appear in the
 foreseeable future.

Responsible-Changed-From-To: bin-bug-people->jruoho
Responsible-Changed-By: jruoho@NetBSD.org
Responsible-Changed-When: Thu, 10 Jun 2010 23:41:10 +0000
Responsible-Changed-Why:
I'll deal with this.


State-Changed-From-To: open->analyzed
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Wed, 20 Apr 2011 07:11:20 +0000
State-Changed-Why:

I will try to fix this for 6.0. The only sane way to do this is to provide  
an ioctl for ACPI and dump the tables directly from the kernel, as done in  
Linux. Preliminary discussion with gsutre@.



>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.