This looks like the (in)famous "implicit return" problem that is in some
Toshiba ASL files.
Method(_CRS) {
CRS_(0x10)
}
This does NOT actually return a value and the ASL code is incorrect. It has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Bob
-----Original Message-----
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Hi,
Could you put the following lines into /boot/loader.conf and send
dmesg output again?
----
debug.acpi.layer="ACPI_ALL_COMPONENTS"
debug.acpi.level="ACPI_LV_ERROR"
----
> [sent privately to not spam the lists with my dump files]
>
> On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote:
>
> > > FYI, I have now a "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_
-
> > > AE_BAD_DATA" with acpica-unix-20020815 during boot.
> >
> > I'd like to make sure if AE_BAD_DATA error occurred w/ previous
> > versions (acpica-unix-20020725, 20020611, 20020404...) ?
> > Or first time w/ acpica-unix-20020815 ?
>
> This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1&con
tent-type=text/x-cvsweb-markup&cvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
