RE: [acpi-jp 2105] Re: ACPI-CA import/new diff?
From: Nate Lawson [mailto:[EMAIL PROTECTED]
http://developer.intel.com/technology/iapc/acp
i/downloads/CHANGES.txt
I'll try to generate a diff soon at post it since I haven't heard from
iwasaki@
Another release is imminent. Or, if you decide to go with what's out
there now there is one little patch that would be good to have, if you
aren't going to import again for a while.
This is against the Linuxized version but you should be able to get the
gist of it:
--- 2421-pre4-acpi/drivers/acpi/events/evgpeblk.c.orig Wed Mar 5
17:00:15 2003
+++ 2421-pre4-acpi/drivers/acpi/events/evgpeblk.c Wed Mar 5
17:01:30 2003
@@ -131,7 +131,7 @@
/* Ensure that we have a valid GPE number for this GPE block */
if ((gpe_number gpe_block-block_base_number) ||
- (gpe_number = (gpe_block-register_count * 8))) {
+ (gpe_number - gpe_block-block_base_number =
(gpe_block-register_count * 8))) {
Regards -- Andy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!
Our web person is out today, so things will be posted Monday at the
earliest.
I'll email Iwasaki-san the latest release, so y'all can get going if you
want.
Regards -- Andy
-Original Message-
From: Moore, Robert
Sent: Wednesday, November 27, 2002 8:28 AM
To: 'Mitsuru IWASAKI'; Grover, Andrew; Moore, Robert
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!
The deleted object problem has been fixed in the 20021122
release which should be available soon, if not already. (I
was able to reproduce the problem with your dsdt on previous
releases, and I verified it fixed with the 11/22 release.)
I did not see any mutex issues -- as we found out on Linux,
the OSL implementation of wait_semaphore is often the culprit.
Bob
-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 12:37 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!
Hi, Intel folks.
It seems that there is a bug in cached object utilization.
This causes strange behavior;
first evaluation of \_SB_.PCI0.LPC_.EC__.BAT0._BST is OK, but
second (or later) evaluation returns AE_TYPE.
acpi_cmbat0: error fetching current battery status -- AE_TYPE
The raw DSDT is at:
http://www.root.org/~nate/acpi/ibm.dsdt
I guess that InternalObject was returned to cache in
AcpiUtReleaseToCache() but the same object is still in use
somewhere (for ResultObj ?).
I could reproduce this problem with acpica debugger. Trace
output attached. I'll track this down later.
Thanks
% acpicadb ibm.dsdt
Loading Acpi table from file ibm.dsdt
utmisc-0802 [11] UtAcquireMutex: Mutex
[ACPI_MTX_Namespace] already acquired by this thread [C25]
utmisc-0802 [11] UtAcquireMutex: Mutex
[ACPI_MTX_Namespace] already acquired by this thread [C25]
Parsing
Methods:..
..
..
..
..
Table [DSDT] - 1208 Objects with 61 Devices 354 Methods 18
Regions Acpi table [DSDT] successfully installed and loaded
- f _BST
\_SB_.PCI0.LPC_.EC__.BAT0._BST (0x80ba0a8) - Method
\_SB_.PCI0.LPC_.EC__.BAT1._BST (0x80ba6a8) - Method
- debug _SB_.PCI0.LPC_.EC__.BAT0._BST
Executing \_SB_.PCI0.LPC_.EC__.BAT0._BST
0 #007F XOr (DerefOf (Index (BT0I, 0x00)))
%
ArgObj:0x80b9ea8 NodeName BT0I Package 0x80e1ba8
ArgObj:0x80f9fa8 Obj Integer
ArgObj:0x80fe028 Obj Integer
0 #0037 [EvalSubTree] (Package (0x0D)
{
0x00,
0x,
0x,
0x01,
0x2A30,
0x00,
0x00,
0x01,
0x01,
,
,
,
})
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
From: Moore, Robert [mailto:[EMAIL PROTECTED]]
1) Fix the ASL so that it compiles without errors or warnings
2) Override the BIOS version of the table with your new one.
(I don't know
how this is done on FreeBSD, someone else will have to help you.
ISTR someone (Iwasaki-san?) had a patch that applied against our code to
workaround this problem. While we won't accept that patch into our release,
why can't you keep using it? Then, we get to keep the moral high ground and
you get fewer problems.
Regards -- Andy
Bob
-Original Message-
From: Yann Berthier [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
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
has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of
this erroneous
code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: [OT] ACPI based support for suspend to disk?
From: Ducrot Bruno [mailto:[EMAIL PROTECTED]] there is a little detail that I don't understand actually. When we want to enter S4 in: sys/contrib/dev/acpica/hwsleep.c::AcpiEnterSleepState we have to fill PM1AControl and PM1BControl with some values deduced by the DSDT. Those values are different, and I am ok with that for S1, S2, etc. But for S4 and S5, there are different too. If I am correct, this implied a different glue logic for the hardware. What is the difference expected for S4 and S5? Good question. On some systems (IBM T20) the values for SLP_TYP registers on the PM1A and 1B Control blocks are the same for S4 and S5. On some (IBM T23) the values between S4 and S5 are different. The only possible difference appears in which wake events might be enabled for the two states. Regards -- Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [OT] ACPI based support for suspend to disk?
From: Michael Nottebrock [mailto:[EMAIL PROTECTED]] You are right. My PC supports this via BIOS too. The disadvantage is, that the bios handle it. I like W2K's feature to do it ACPI based (?). This gives my the freedom to suspend my W2K to disk and to reboot with FBSD. Later I reboot again and choose W2K and it restores it previous state. If the bios does it, it restores always the last suspended OS. AFAIR, the Win2k-Suspend2Disk is not ACPI-based. Win2k suspend to disk (STD) (aka hibernate aka ACPI S4) is using ACPI. ACPI defines 2 kinds of STD, S4 and S4BIOS. S4 is completely done by the operating system, and then uses the ACPI interface to turn the system off. S4BIOS...uses the BIOS, usually to a dedicated suspend partition. Having the OS save the system image to disk is generally considered the way to go. But of course that requires that your OS have that added capability. So yes I guess you *are* right in that ACPI doesn't actually do the suspend to disk, but it is involved in the process. Regards -- Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
