From owner-acpi-jp@jp.freebsd.org  Tue Sep 25 23:31:24 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id XAA11094;
	Tue, 25 Sep 2001 23:31:24 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id XAA11089
	for <acpi-jp@jp.freebsd.org>; Tue, 25 Sep 2001 23:31:24 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id f8PEVMm12858;
	Tue, 25 Sep 2001 23:31:22 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Date: Tue, 25 Sep 2001 23:31:19 +0900 (JST)
Message-Id: <20010925.233119.07584163.iwasaki@jp.FreeBSD.org>
To: acpi-jp@jp.freebsd.org
Cc: robert.moore@intel.com, andrew.grover@intel.com
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
In-Reply-To: <7mpu8gc9th.wl@waterblue.imgsrc.co.jp>
References: <ywlvgigu0k2.fsf@cerberus.proc.flab.fujitsu.co.jp>
	<7mpu8gc9th.wl@waterblue.imgsrc.co.jp>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1301
Subject: [acpi-jp 1301] Re: Stopped at AcpiExTruncateFor32bitTable+0x13
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

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=freebsd-jp
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/CF-A2R4H2.dsdt?cvsroot=freebsd-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





