From owner-acpi-jp@jp.freebsd.org  Wed Sep 26 02:14:25 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id CAA18476;
	Wed, 26 Sep 2001 02:14:25 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id CAA18470;
	Wed, 26 Sep 2001 02:14:23 +0900 (JST)
	(envelope-from robert.moore@intel.com)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.43 2001/09/24 21:10:20 root Exp $) with SMTP id RAA03029;
	Tue, 25 Sep 2001 17:14:19 GMT
Received: from fmsmsx17.intel.com ([132.233.58.209])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001092510135412049
 ; Tue, 25 Sep 2001 10:13:54 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <TR7V3LY7>; Tue, 25 Sep 2001 10:16:19 -0700
Message-ID: <B9ECACBD6885D5119ADC00508B68C1EA2FDF29@orsmsx107.jf.intel.com>
From: "Moore, Robert" <robert.moore@intel.com>
To: "'Mitsuru IWASAKI'" <iwasaki@jp.FreeBSD.org>, acpi-jp@jp.FreeBSD.org
Cc: "Moore, Robert" <robert.moore@intel.com>,
        "Grover, Andrew" <andrew.grover@intel.com>
Date: Tue, 25 Sep 2001 10:14:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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+010328
X-Sequence: acpi-jp 1302
Subject: [acpi-jp 1302] RE: Stopped at AcpiExTruncateFor32bitTable+0x1
	3
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: robert.moore@intel.com


I don't think that the code path you are postulating can ever happen.  There
is even a comment in nseval that explains how it can get away with passing
in a NULL for WalkState.  Since ObjDesc is an actual operand object and not
a namespace node, AcpeExResolveNodeToValue should never be called.

However, the exact stack trace of what has happened will be needed.

Bob


		-----Original Message-----
		From:	Mitsuru IWASAKI [mailto:iwasaki@jp.FreeBSD.org]
		Sent:	Tuesday, September 25, 2001 7:31 AM
		To:	acpi-jp@jp.FreeBSD.org
		Cc:	robert.moore@intel.com; andrew.grover@intel.com
		Subject:	Re: [acpi-jp 1300] Re: Stopped at
AcpiExTruncateFor32bitTable+0x13

		Hi, Intel folks.  I haven't figure out what the problem is,
but
		I've found a potential bug in
nseval.c:AcpiNsGetObjectValue().

		> FYI.  I got same thing with my new notebook (Panasonic
CF-A2R4H2).

		OK, I added your ACPI data to our collection.
	
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/CF-A2R4H2.asl?cvsroot=fre
ebsd-jp
	
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/CF-A2R4H2.dsdt?cvsroot=fr
eebsd-jp

		> At Tue, 18 Sep 2001 12:49:34 +0000 (UTC),
		> TOMITA Yoshinori wrote:
		> > >Fatal trap 12: page fault while in kernel mode
		> > >fault virtual address   = 0x40
		> > >fault code              = supervisor read, page not
present
		> > >instruction pointer     = 0x8:0xc0498de7
		> > >stack pointer           = 0x10:0xc04e1d18
		> > >frame pointer           = 0x10:0xc04e1d18
		> > >code segment            = base 0x0, limit 0xfffff, type
0x1b
		> > >                        = DPL 0, pres 1, def32 1, gran
1
		> > >processor eflags        = interrupt enabled, resume,
IOPL = 0
		> > >current process         = 0 (swapper)
		> > >kernel: type 12 trap, code=0
		> > >Stopped at      AcpiExTruncateFor32bitTable+0x13:
cmpl   $0,0x40(%eax)

		Could someone show us the back trace of this?  Just type `t'
here in DDB.

		In nseval.c:AcpiNsGetObjectValue(),
		        AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE);
		        Status = AcpiExEnterInterpreter ();
		        if (ACPI_SUCCESS (Status))
		        {
		            Status = AcpiExResolveToValue (&ObjDesc, NULL);

		AcpiExResolveToValue() passes NULL as WalkState, then this
NULL will be
		passed to
		exresolv.c:AcpiExResolveToValue()
		exresnte.c:AcpiExResolveNodeToValue()
		and finally it can reach
exutils.c:AcpiExTruncateFor32bitTable().
		Yes this can be a problem, but I'm not sure whether this is
the exact
		cause of panic reported...

		Thanks




		
