ACPI owner_id limit too low

PATCH Alex Williamson 2 participants 3 messages Dec 8, 2005

Subsystems (2)

ACPI ACPI component architecture (acpica)

lore

Share & tools

lore

Alex Williamson

author

2005-12-08 18:21 UTC #0 lore raw

We've found recently that it's not very hard to bump into the limit
of the number of owner_ids that the ACPI subsystem can provide. This is not because of leaks or complicated method execution, but simply because our ACPI namespace is describing a complicated system and includes a large number of SSDT tables. We end up using far more than half the owner_ids statically allocated for these tables. The ACPI subsystem has a limit of 256 ACPI tables, but we'd have a hard time getting within an order of magnitude of that number and still have enough owner_ids available for method execution. I hear rumor that the next CA release increases this limit, but given that the in kernel CA revision often lags by several months, I'm wondering if we can bump up this limit in the interim. Doubling the limit to 64 is a sufficient short term fix and a fairly trivial patch, maybe even something that could go in before 2.6.15. Len, could we do something like the below patch to give us a little more reasonable limit? We could switch to a bitmap too, but given how close the next kernel is to release this is less impact. Thanks,

Alex

Signed-off-by Alex Williamson <[email protected]>

---

drivers/acpi/utilities/utmisc.c +9 -9

diff -r 03055821672a drivers/acpi/utilities/utmisc.c
@@ -84,14 +84,14 @@
 
 	/* Find a free owner ID */
 
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
+	for (i = 0; i < 64; i++) {
+		if (!(acpi_gbl_owner_id_mask & (1UL << i))) {
 			ACPI_DEBUG_PRINT((ACPI_DB_VALUES,
-					  "Current owner_id mask: %8.8X New ID: %2.2X\n",
+					  "Current owner_id mask: %16.16lX New ID: %2.2X\n",
 					  acpi_gbl_owner_id_mask,
 					  (unsigned int)(i + 1)));
 
-			acpi_gbl_owner_id_mask |= (1 << i);
+			acpi_gbl_owner_id_mask |= (1UL << i);
 			*owner_id = (acpi_owner_id) (i + 1);
 			goto exit;
 		}

@@ -106,7 +106,7 @@
 	 */
 	*owner_id = 0;
 	status = AE_OWNER_ID_LIMIT;
-	ACPI_REPORT_ERROR(("Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT\n"));
+	ACPI_REPORT_ERROR(("Could not allocate new owner_id (64 max), AE_OWNER_ID_LIMIT\n"));
 
       exit:
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);

@@ -123,7 +123,7 @@
  *              control method or unloading a table. Either way, we would
  *              ignore any error anyway.
  *
- * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 32
+ * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 64
  *
  ******************************************************************************/

@@ -140,7 +140,7 @@
 
 	/* Zero is not a valid owner_iD */
 
-	if ((owner_id == 0) || (owner_id > 32)) {
+	if ((owner_id == 0) || (owner_id > 64)) {
 		ACPI_REPORT_ERROR(("Invalid owner_id: %2.2X\n", owner_id));
 		return_VOID;
 	}

@@ -158,8 +158,8 @@
 
 	/* Free the owner ID only if it is valid */
 
-	if (acpi_gbl_owner_id_mask & (1 << owner_id)) {
-		acpi_gbl_owner_id_mask ^= (1 << owner_id);
+	if (acpi_gbl_owner_id_mask & (1UL << owner_id)) {
+		acpi_gbl_owner_id_mask ^= (1UL << owner_id);
 	}
 
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);

include/acpi/acglobal.h +1 -1

diff -r 03055821672a include/acpi/acglobal.h
@@ -211,7 +211,7 @@
 ACPI_EXTERN u32 acpi_gbl_rsdp_original_location;
 ACPI_EXTERN u32 acpi_gbl_ns_lookup_count;
 ACPI_EXTERN u32 acpi_gbl_ps_find_count;
-ACPI_EXTERN u32 acpi_gbl_owner_id_mask;
+ACPI_EXTERN u64 acpi_gbl_owner_id_mask;
 ACPI_EXTERN u16 acpi_gbl_pm1_enable_register_save;
 ACPI_EXTERN u16 acpi_gbl_global_lock_handle;
 ACPI_EXTERN u8 acpi_gbl_debugger_configuration;

Carl-Daniel Hailfinger

2005-12-08 20:23 UTC #1 lore raw

Quoted 19 lines · Alex Williamson

We've found recently that it's not very hard to bump into the limit
of the number of owner_ids that the ACPI subsystem can provide. [...] Doubling the limit to 64 is a sufficient short term fix and a fairly trivial patch, maybe even something that could go in before 2.6.15. Len, could we do something like the below patch to give us a little more reasonable limit? We could switch to a bitmap too, but given how close the next kernel is to release this is less impact. Thanks,
Alex
Signed-off-by Alex Williamson <[email protected]>
---
diff -r 03055821672a drivers/acpi/utilities/utmisc.c

drivers/acpi/utilities/utmisc.c line 88

Quoted 7 lines

drivers/acpi/utilities/utmisc.c +2 -2

@@ -84,14 +84,14 @@
 
 	/* Find a free owner ID */
 
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
+	for (i = 0; i < 64; i++) {
+		if (!(acpi_gbl_owner_id_mask & (1UL << i))) {

Shouldn't this be 1ULL if you intend it to be 64 bit wide on a 32 bit arch?

Regards,
Carl-Daniel

Signature · 8 lines

http://www.hailfinger.org/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Alex Williamson

author

2005-12-08 20:36 UTC #2 lore raw

Quoted 7 lines · Carl-Daniel Hailfinger

Review
Quoted 4 lines
(quoted diff) +2 -2
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
+	for (i = 0; i < 64; i++) {
+		if (!(acpi_gbl_owner_id_mask & (1UL << i))) {
Shouldn't this be 1ULL if you intend it to be 64 bit wide on a 32 bit arch?

Yes, sorry I overlooked that. Here's an updated patch. Thanks,

Alex

Signed-off-by Alex Williamson <[email protected]>

---

drivers/acpi/utilities/utmisc.c +9 -9

diff -r 03055821672a drivers/acpi/utilities/utmisc.c
@@ -84,14 +84,14 @@
 
 	/* Find a free owner ID */
 
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
+	for (i = 0; i < 64; i++) {
+		if (!(acpi_gbl_owner_id_mask & (1ULL << i))) {
 			ACPI_DEBUG_PRINT((ACPI_DB_VALUES,
-					  "Current owner_id mask: %8.8X New ID: %2.2X\n",
+					  "Current owner_id mask: %16.16lX New ID: %2.2X\n",
 					  acpi_gbl_owner_id_mask,
 					  (unsigned int)(i + 1)));
 
-			acpi_gbl_owner_id_mask |= (1 << i);
+			acpi_gbl_owner_id_mask |= (1ULL << i);
 			*owner_id = (acpi_owner_id) (i + 1);
 			goto exit;
 		}

@@ -106,7 +106,7 @@
 	 */
 	*owner_id = 0;
 	status = AE_OWNER_ID_LIMIT;
-	ACPI_REPORT_ERROR(("Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT\n"));
+	ACPI_REPORT_ERROR(("Could not allocate new owner_id (64 max), AE_OWNER_ID_LIMIT\n"));
 
       exit:
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);

@@ -123,7 +123,7 @@
  *              control method or unloading a table. Either way, we would
  *              ignore any error anyway.
  *
- * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 32
+ * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 64
  *
  ******************************************************************************/

@@ -140,7 +140,7 @@
 
 	/* Zero is not a valid owner_iD */
 
-	if ((owner_id == 0) || (owner_id > 32)) {
+	if ((owner_id == 0) || (owner_id > 64)) {
 		ACPI_REPORT_ERROR(("Invalid owner_id: %2.2X\n", owner_id));
 		return_VOID;
 	}

@@ -158,8 +158,8 @@
 
 	/* Free the owner ID only if it is valid */
 
-	if (acpi_gbl_owner_id_mask & (1 << owner_id)) {
-		acpi_gbl_owner_id_mask ^= (1 << owner_id);
+	if (acpi_gbl_owner_id_mask & (1ULL << owner_id)) {
+		acpi_gbl_owner_id_mask ^= (1ULL << owner_id);
 	}
 
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);

include/acpi/acglobal.h +1 -1

diff -r 03055821672a include/acpi/acglobal.h
@@ -211,7 +211,7 @@
 ACPI_EXTERN u32 acpi_gbl_rsdp_original_location;
 ACPI_EXTERN u32 acpi_gbl_ns_lookup_count;
 ACPI_EXTERN u32 acpi_gbl_ps_find_count;
-ACPI_EXTERN u32 acpi_gbl_owner_id_mask;
+ACPI_EXTERN u64 acpi_gbl_owner_id_mask;
 ACPI_EXTERN u16 acpi_gbl_pm1_enable_register_save;
 ACPI_EXTERN u16 acpi_gbl_global_lock_handle;
 ACPI_EXTERN u8 acpi_gbl_debugger_configuration;

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click