From owner-acpi-jp@jp.freebsd.org  Thu Mar  8 07:48:02 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id HAA67901;
	Thu, 8 Mar 2001 07:48:02 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id HAA67896
	for <acpi-jp@jp.freebsd.org>; Thu, 8 Mar 2001 07:48:01 +0900 (JST)
	(envelope-from robert.moore@intel.com)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id WAA29738;
	Wed, 7 Mar 2001 22:47:13 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 07 Mar 2001 22:47:15 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <GGAS14RG>; Wed, 7 Mar 2001 14:47:14 -0800
Message-ID: <7B1A3FD0E515D211AC3E00A0C96B7AC907C8CF61@orsmsx34.jf.intel.com>
From: "Moore, Robert" <robert.moore@intel.com>
To: "'acpi-jp@jp.freebsd.org'" <acpi-jp@jp.freebsd.org>, andrea@webcom.it
Date: Wed, 7 Mar 2001 14:40:39 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1100
Subject: [acpi-jp 1100] RE: ACPICA: new bug related with local variable (B
	ug in battery support in IBM Thinkpad?)
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: robert.moore@intel.com


The problem is that we have deployed "implicit operand conversion" as
defined in the ACPI 2.0 specification (ASL Data Types section) -- and we are
now faced with the issue of how to implement backward compatibility with
existing code that expects a Store operator to always overwrite the contents
of a local.  I suspect that we will use the revision level field of the
table header - just as we do to make the decision as to internal integer
width (32 vs. 64).

What is happening is that the Buffer object is being converted to an Integer
because that is the existing type of Local0.

Bob Moore


		-----Original Message-----
		From:	Mitsuru IWASAKI [mailto:iwasaki@jp.freebsd.org]
		Sent:	Wednesday, March 07, 2001 6:48 AM
		To:	acpi-jp@jp.freebsd.org; andrea@webcom.it
		Subject:	[acpi-jp 1099] ACPICA: new bug related with
local variable (Bug in battery support in IBM Thinkpad?)

		Intel folks: I've found a new bug in ACPICA interpreter
code.  Storing
		different type of value to local variable (in this case
Buffer to
		Integer) seems to have a problem.

		> > > By the way, did you have a look at my ASL file? I'm
not an expert but it
		> > > _BIF and _BST entries look suspicious to me...
		> > 
		> > That is not so strange for me.  I wrote simple asl for
the test,
		> > executed it with acpicadb, and got a normal result.
		> > 
		> >         Name(BSTB, Package(0x4) {
		> >             0x0,
		> >             0xffffffff,
		> >             0xffffffff,
		> >             0xffffffff,
		> >         })
		> > 		:
		> >         Method(_BIF) {
		> > 		:
		> >             Store("LION", Index(BIFB, 0xb, ))
		> >             Return(BIFB)
		> >         }
		> > 
		> > And we have a almost same ACPI data with yours, not
TP570E but TP570.
		> >
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/TP570.asl?cvsroot=freebsd
-jp
		> 
		> Ok if it's not my machine, then there must be something
wrong in how we parse
		> the ASL; but if so, why wasn't it showing up on everybody
else's machine?
		> 
		> Here we have a structure full of bogus data. I saw nothing
really strange in
		> our dev/acpi, so it's probably in the contrib/ code... I
even tried enabiling
		> DEBUG for most of the layers/levels, but the I get so much
debugging that my
		> serial couln't possibly handle!!

		I executed your TP570E.dsdt with acpicadb, _BIF surely gave
me a error.
		The problem is in \_SB_.PCI_.ISA_.EC__.SMRA().  ASL is OK,
but
		interpreter seems to have a bug.

		                Method(SMRA, 2) {
		                    Acquire(SMMB, 0xffff)
		                    Name(INVB, Buffer(0x21) {0xff, 0xff, ...
0xff, 0x0 })
		                    Store(SMBP(0xb, Arg0, Arg1), Local0)
# Integer.
		                    If(Local0) {
		                        Store(INVB, Local0)	# Buffer,
but still Integer.
		                    }
		                    Else {
		                        Store(0x0, Local1)
		                        While(LLess(Local1, 0x21)) {   
		                            PUTB(INVB, Local1,
ECRD(Add(0x54, Local1, )))
		                            Increment(Local1)
		                        }
		                        Store(INVB, Local0)	# Buffer,
but still Integer
		                    }
		                    Release(SMMB)
		                    Return(Local0)		# Integer
		                }

		And caller side, error occurred and stopped at
CreateDWordField().
		        Method(_BIF) {
		            Store(\_SB_.PCI_.ISA_.EC__.GH8A(), Local0)
# Integer
		            Store(\_SB_.PCI_.ISA_.EC__.SMRA(Local0, 0x10),
Local0)
							# Buffer expected,
but actually Integer.
		            CreateByteField(Local0, 0x0, PWUT)
		            CreateDWordField(Local0, 0x4, DCAP)

		The message was:

		ArgObj:    0x80c7200 <Obj> [Local0]    Integer FFFFFFFF
		ArgObj:    0x80c7300 <Obj>             Integer 00000004
		ArgObj:    0x80c80a0 <Node>            Name DCAP
Type-FieldUnit
		dsopcode-0599: AmlExecCreateField: Field exceeds Buffer 64 >
32
		Outstanding: 28 allocations of total size 1212 after
execution
		Execution of \_SB_.BAT1._BIF failed with status
AE_AML_BUFFER_LIMIT

		I wrote and compile a simple ASL to reproduce the problem
and
		confirmed the same error running with acpicadb.

		Method(AAAA)
		{
		        Name(INVB, Buffer(10) {0, 1, 2, 3, 4, 5, 6, 7, 8,
9})
		        Store(0x1f, Local0)
		        Store(INVB, Local0)
		        CreateByteField(Local0, 0x0, PWUT)
		        CreateDWordField(Local0, 0x4, DCAP)
		}

		I'll look at this more if I can get enough time, but I'll be
busy for
		a few days...

		Thanks

