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
]; [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
On Tue, 27 Aug 2002, Mitsuru IWASAKI wrote:
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
Of course, here we go :)
[sent privately to not spam the lists
Moore, Robert wrote:
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:
-jp 1735] Re: Call for testers: acpica-unix-20020815
Moore, Robert wrote:
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
Moore, Robert wrote:
Well, the *real* problem is that there is no Return AML opcode in the
control method and the interpreter therefore does not return a value.
However, to answer your question with a question:
Would you ask a C compiler, or any other compiler for that matter, to
: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Moore, Robert wrote:
Well, the *real* problem is that there is no Return AML opcode in the
control method and the interpreter therefore does not return a value.
However, to answer your question with a question:
Would you ask a C
On Tue, 27 Aug 2002, Moore, Robert wrote:
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
Moore, Robert wrote:
I think you are missing something:
1) BIOS vendor writes ASL
2) BIOS vendor compiles ASL to AML byte-code
3) BIOS vendor puts AML into BIOS
4) OS gets AML from the BIOS
5) OS interprets AML
The error you are experiencing is in (5). There is no return statement in
, 2002 3:40 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Moore, Robert wrote:
I think you are missing something:
1) BIOS vendor writes ASL
2) BIOS vendor
Thus spake Terry Lambert [EMAIL PROTECTED]:
FWIW, there's historical precedent for this: the DEC VAX/VMS
C compiler would imply semicolons for the programmer that
forgot them, and a couple of other similar fixups, issue a
warning, but the resulting code would run as the programmer
most
David Schultz wrote:
So the worst possible outcome in the failure case is that it
fails -- which it already does, without the assumption -- and
the best possible outcome is that it succeeds when it wouldn't
have.
Anything that works is better than anything that doesn't
Sometimes.
Thus spake Terry Lambert [EMAIL PROTECTED]:
Sometimes. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html
I understand, but having a different failure is no worse than
having a failure, I think. In either case, it doesn't work,
even if it doesn't work in an entirely different
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 ?
Anyway,
14 matches
Mail list logo
