Reserved method has too many arguments (_OSC requires 4)
by Thomas Renninger
Hi,
I have a laptop freezing early, acpi=off and noapic helps.
I wonder whether this could have to do with the broken _OSC method.
I cannot access the machine myself, eventually I can get more info
if needed, but the machine is freezing really early (after ACPI
initialization, somewhere around bringing up CPUs (possibly when
starting PCI init already?).
This is not the first time I see this message.
It would be great to get (from include/linux/kernel.h):
#define FW_BUG "[Firmware Bug]: "
#define FW_WARN "[Firmware Warn]: "
#define FW_INFO "[Firmware Info]: "
marked messages into ACPICA and blame the guys who are responsible
for that.
My other concern/question is: what exactly happens in such a case?
Will _OSC get invoked at all?
If yes, what will be the last argument, zero, -1?
Hmm, I doubt it has to do with the freeze, but it would still be
great if someone knowing these parts could comment what people
with such a BIOS could expect to happen.
Thanks,
Thomas
Method (_OSC, 5, NotSerialized)
{
Store (Arg3, Local0)
Multiply (Local0, 0x04, Local1)
Name (BUF1, Buffer (Local1) {})
Store (Arg4, BUF1)
Store (Zero, Local1)
Store (Zero, Local2)
While (Local0)
{
Multiply (Local1, 0x04, Local2)
CreateDWordField (BUF1, Local2, CAPB)
If (Arg2)
{
If (LEqual (Local1, Zero))
{
And (CAPB, 0xFFFFFFFC)
}
}
Increment (Local1)
Decrement (Local0)
}
Return (BUF1)
}
11 years, 4 months
Prefer 32 bit addresses over 64 ones
by Thomas Renninger
Hi,
you probably know this already, I just stumbled
over this:
http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174c...
We prefer 32 bit addresses over 64 ones if they are
not equal, which helped for some broken BIOSes
from pre-Vista times.
Now it's the other way around:
If the FADT Revision field is > 2,
Windows Vista will use the extended
64-bit addresses in the FADT
X_FIRMWARE_CTRL and X_DSDT
Extended addresses of ACPI fixed hardware
X_PM1a_EVT_BLK, etc.
Just for info...
Thomas
11 years, 8 months
[PATCH] ACPICA: Do not hang at mutex forever if BIOS tries to release global lock
by Thomas Renninger
Hi,
find the code against the Linux kernel pasted at the end
of the mail for review.
Find the code adjusted for ACPICA inclusion in the
attachement.
Bob: If you are ok with the patch, it would be great
if you could push it. Be aware that I did not compile
tested it in ACPICA environment.
Thanks,
Thomas
From: Stuart Hayes <stuart_hayes(a)dell.com>
ACPICA: Do not hang at mutex forever if BIOS tries to release global lock
and OS did not request the lock (means the pending bit was not set).
Which in fact is a BIOS/HW bug (compare with ACPI Spec 3.0b):
5.2.10.1 Global Lock:
..
This signal only occurs when the other environment attempted to acquire
ownership while the lock was owned.
..
or
4.7.3.1.1 PM1 Status Registers
GBL_STS:
..
This bit is set in response to the BIOS releasing control of the Global Lock
and having seen the pending bit set.
..
There seem to be chipsets which can get this wrong (especially after a kexec
boot on Linux).
Also one could theoretically run into this if a new kernel got booted without
proper reboot and BIOS re-initialization (like kexec) while:
1) The OS hold the global lock
2) The BIOS hold the global lock
This patch would handle condition 1.
To make sure condition 2. cannot happen, it should get stated in the ACPI spec
that the global lock needs to be zeroed by BIOS everytime the OS tries to
(re-)enable ACPI mode.
Modifications by trenn:
- Add a message -> This should not happen and if it happens it should not
be ignored/handled silently
- Adjusted from Linux kernel to acpica sources
Signed-off-by: Thomas Renninger <trenn(a)suse.de>
diff -purN '--exclude=*orig' linux-2.6.36-rc6_orig/drivers/acpi/acpica/acglobal.h linux-2.6.36-rc6/drivers/acpi/acpica/acglobal.h
--- linux-2.6.36-rc6_orig/drivers/acpi/acpica/acglobal.h 2010-06-02 09:16:14.000000000 -0500
+++ linux-2.6.36-rc6/drivers/acpi/acpica/acglobal.h 2010-06-02 09:24:44.000000000 -0500
@@ -213,6 +213,7 @@ ACPI_EXTERN acpi_semaphore acpi_gbl_glob
ACPI_EXTERN u16 acpi_gbl_global_lock_handle;
ACPI_EXTERN u8 acpi_gbl_global_lock_acquired;
ACPI_EXTERN u8 acpi_gbl_global_lock_present;
+ACPI_EXTERN u32 acpi_gbl_global_lock_pending;
/*
* Spinlocks are used for interfaces that can be possibly called at
diff -purN '--exclude=*orig' linux-2.6.36-rc6_orig/drivers/acpi/acpica/evmisc.c linux-2.6.36-rc6/drivers/acpi/acpica/evmisc.c
--- linux-2.6.36-rc6_orig/drivers/acpi/acpica/evmisc.c 2010-06-02 09:16:11.000000000 -0500
+++ linux-2.6.36-rc6/drivers/acpi/acpica/evmisc.c 2010-06-02 09:24:45.000000000 -0500
@@ -297,6 +297,17 @@ static u32 acpi_ev_global_lock_handler(v
{
u8 acquired = FALSE;
+ /* This must not happen: BIOS must only release the lock if OS has set
+ * it pending. Such inconsistancies could happen if the global lock bits
+ * survived through a kexec boot. */
+
+ if (!acpi_gbl_global_lock_pending) {
+ u8 pending;
+ /* Clear lock bits. BIOS released lock and OS isn't waiting. */
+ ACPI_RELEASE_GLOBAL_LOCK(acpi_gbl_FACS, pending);
+ return (ACPI_INTERRUPT_HANDLED);
+ }
+
/*
* Attempt to get the lock.
*
@@ -309,6 +320,7 @@ static u32 acpi_ev_global_lock_handler(v
/* Got the lock, now wake all threads waiting for it */
acpi_gbl_global_lock_acquired = TRUE;
+ acpi_gbl_global_lock_pending--;
/* Send a unit to the semaphore */
if (ACPI_FAILURE
@@ -479,6 +491,8 @@ acpi_status acpi_ev_acquire_global_lock(
acpi_gbl_global_lock_acquired = TRUE;
return_ACPI_STATUS(AE_OK);
+ } else {
+ acpi_gbl_global_lock_pending++;
}
/*
diff -purN '--exclude=*orig' linux-2.6.36-rc6_orig/drivers/acpi/acpica/utglobal.c linux-2.6.36-rc6/drivers/acpi/acpica/utglobal.c
--- linux-2.6.36-rc6_orig/drivers/acpi/acpica/utglobal.c 2010-06-02 09:16:14.000000000 -0500
+++ linux-2.6.36-rc6/drivers/acpi/acpica/utglobal.c 2010-06-02 09:24:45.000000000 -0500
@@ -782,6 +782,7 @@ acpi_status acpi_ut_init_globals(void)
acpi_gbl_global_lock_acquired = FALSE;
acpi_gbl_global_lock_handle = 0;
acpi_gbl_global_lock_present = FALSE;
+ acpi_gbl_global_lock_pending = 0;
/* Miscellaneous variables */
11 years, 8 months
[PATCH] ACPICA: Sanity check global lock bits before ACPI mode is enabled
by Thomas Renninger
Be careful, not even compile tested!
Reason for moving AcpiTbInitializeFacs:
Doing the sanity check shortly after enabling ACPI mode may more often show:
if (AcpiGbl_FACS.GlobalLock & 0x1) {
ACPI_INFO ((AE_INFO, "Global lock acquired by BIOS before"
" ACPI mode got enabled"));
Because it's expected that BIOS may do quite some HW accesses when acpi
got enabled (assumption).
CC: Lin Ming <ming.m.lin(a)intel.com>
CC: Len Brown <lenb(a)kernel.org>
CC: Rafael Wysocki <rjw(a)suse.com>
CC: devel(a)acpica.org
Signed-off-by: Thomas Renninger <trenn(a)suse.de>
---
source/components/tables/tbutils.c | 21 +++++++++++++++++++--
source/components/utilities/utxface.c | 23 ++++++++++++-----------
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/source/components/tables/tbutils.c b/source/components/tables/tbutils.c
index 100a91d..4562e9b 100644
--- a/source/components/tables/tbutils.c
+++ b/source/components/tables/tbutils.c
@@ -159,10 +159,27 @@ AcpiTbInitializeFacs (
{
ACPI_STATUS Status;
-
Status = AcpiGetTableByIndex (ACPI_TABLE_INDEX_FACS,
ACPI_CAST_INDIRECT_PTR (ACPI_TABLE_HEADER, &AcpiGbl_FACS));
- return (Status);
+
+ if (ACPI_FAILURE (Status))
+ return (Status);
+
+ /*
+ * Do some sanity checks on the Global Lock: A value of 0x1 is
+ * possible but could be a hint for a hard to debug issue.
+ * A value of 0x3 must not happen, but we try to handle it gracefully.
+ */
+ if (AcpiGbl_FACS.GlobalLock & 0x1) {
+ ACPI_INFO ((AE_INFO, "Global lock acquired by BIOS before"
+ " ACPI mode got enabled"));
+ if (AcpiGbl_FACS.GlobalLock & 0x3) {
+ ACPI_ERROR ((AE_INFO, "Found stale global lock pending bits"));
+ AcpiGbl_FACS.GlobalLock &= ~0x3;
+ }
+ }
+
+ return (AE_OK);
}
diff --git a/source/components/utilities/utxface.c b/source/components/utilities/utxface.c
index 9e52017..0819135 100644
--- a/source/components/utilities/utxface.c
+++ b/source/components/utilities/utxface.c
@@ -193,6 +193,18 @@ AcpiInitializeSubsystem (
return_ACPI_STATUS (Status);
}
+ /*
+ * Obtain a permanent mapping for the FACS. This is required for the
+ * Global Lock and the Firmware Waking Vector
+ */
+ Status = AcpiTbInitializeFacs ();
+ if (ACPI_FAILURE (Status))
+ {
+ ACPI_WARNING ((AE_INFO, "Could not map the FACS table"));
+ return_ACPI_STATUS (Status);
+ }
+
+
/* Initialize the global OSI interfaces list with the static names */
Status = AcpiUtInitializeInterfaces ();
@@ -251,17 +263,6 @@ AcpiEnableSubsystem (
}
/*
- * Obtain a permanent mapping for the FACS. This is required for the
- * Global Lock and the Firmware Waking Vector
- */
- Status = AcpiTbInitializeFacs ();
- if (ACPI_FAILURE (Status))
- {
- ACPI_WARNING ((AE_INFO, "Could not map the FACS table"));
- return_ACPI_STATUS (Status);
- }
-
- /*
* Install the default OpRegion handlers. These are installed unless
* other handlers have already been installed via the
* InstallAddressSpaceHandler interface.
--
1.6.3
11 years, 8 months
ACPICA version 20101013 released
by Moore, Robert
13 October 2010. Summary of changes for version 20101013:
This release is available at www.acpica.org/downloads
1) ACPI CA Core Subsystem:
Added support to clear the PCIEXP_WAKE event. When clearing ACPI events, now clear the PCIEXP_WAKE_STS bit in the ACPI PM1 Status Register, via HwClearAcpiStatus. Original change from Colin King. ACPICA BZ 880.
Changed the type of the predefined namespace object _TZ from ThermalZone to Device. This was found to be confusing to the host software that processes the various thermal zones, since _TZ is not really a ThermalZone. However, a Notify() can still be performed on it. ACPICA BZ 876. Suggestion from Rui Zhang.
Added Windows Vista SP2 to the list of supported _OSI strings. The actual string is "Windows 2006 SP2".
Eliminated duplicate code in AcpiUtExecute* functions. Now that the nsrepair code automatically repairs _HID-related strings, this type of code is no longer needed in Execute_HID, Execute_CID, and Execute_UID. ACPICA BZ 878.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Previous Release:
Non-Debug Version: 89.9K Code, 19.0K Data, 108.9K Total
Debug Version: 166.3K Code, 52.1K Data, 218.4K Total
Current Release:
Non-Debug Version: 89.9K Code, 19.0K Data, 108.9K Total
Debug Version: 166.3K Code, 52.1K Data, 218.4K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Implemented additional compile-time validation for _HID strings. The non-hex prefix (such as "PNP" or "ACPI") must be uppercase, and the length of the string must be exactly seven or eight characters. For both _HID and _CID strings, all characters must be alphanumeric. ACPICA BZ 874.
iASL: Allow certain "null" resource descriptors. Some BIOS code creates descriptors that are mostly or all zeros, with the expectation that they will be filled in at runtime. iASL now allows this as long as there is a "resource tag" (name) associated with the descriptor, which gives the ASL a handle needed to modify the descriptor. ACPICA BZ 873.
Added single-thread support to the generic Unix application OSL. Primarily for iASL support, this change removes the use of semaphores in the single-threaded ACPICA tools/applications - increasing performance. The _MULTI_THREADED option was replaced by the (reverse) ACPI_SINGLE_THREADED option. ACPICA BZ 879.
AcpiExec: several fixes for the 64-bit version. Adds XSDT support and support for 64-bit DSDT/FACS addresses in the FADT. Lin Ming.
iASL: Moved all compiler messages to a new file, aslmessages.h.
11 years, 8 months