2005-12-08 22:04:12

by Moore, Robert

[permalink] [raw]
Subject: RE: [ACPI] ACPI owner_id limit too low

We have increased the number of owner IDs to 255 in the most recent
version of ACPICA, 20051202. This should hit Linux soon.

Additionally, we plan to conserve OwnerIDs by not using them for tables
that can never be unloaded, to be implemented in a future release.
However, 255 Ids should be plenty for now.

Here is the text from the release memo:

Increased the number of available Owner Ids for namespace object
tracking from 32 to 255. This should eliminate the OWNER_ID_LIMIT
exceptions seen on some machines with a large number of ACPI tables
(either static or dynamic).


Bob


> -----Original Message-----
> From: [email protected] [mailto:acpi-devel-
> [email protected]] On Behalf Of Alex Williamson
> Sent: Thursday, December 08, 2005 12:37 PM
> To: Carl-Daniel Hailfinger
> Cc: Brown, Len; [email protected]; acpi-
> [email protected]
> Subject: Re: [ACPI] ACPI owner_id limit too low
>
> On Thu, 2005-12-08 at 21:23 +0100, Carl-Daniel Hailfinger wrote:
>
> > > - 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]>
> ---
>
> diff -r 03055821672a drivers/acpi/utilities/utmisc.c
> --- a/drivers/acpi/utilities/utmisc.c Mon Dec 5 01:00:10 2005
> +++ b/drivers/acpi/utilities/utmisc.c Wed Dec 7 14:55:58 2005
> @@ -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);
> diff -r 03055821672a include/acpi/acglobal.h
> --- a/include/acpi/acglobal.h Mon Dec 5 01:00:10 2005
> +++ b/include/acpi/acglobal.h Wed Dec 7 14:55:58 2005
> @@ -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
> _______________________________________________
> Acpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


2005-12-08 22:21:24

by Alex Williamson

[permalink] [raw]
Subject: RE: [ACPI] ACPI owner_id limit too low

On Thu, 2005-12-08 at 14:03 -0800, Moore, Robert wrote:
> We have increased the number of owner IDs to 255 in the most recent
> version of ACPICA, 20051202. This should hit Linux soon.
>
> Additionally, we plan to conserve OwnerIDs by not using them for tables
> that can never be unloaded, to be implemented in a future release.
> However, 255 Ids should be plenty for now.
>
> Here is the text from the release memo:
>
> Increased the number of available Owner Ids for namespace object
> tracking from 32 to 255. This should eliminate the OWNER_ID_LIMIT
> exceptions seen on some machines with a large number of ACPI tables
> (either static or dynamic).

Hi Bob,

Sorry if I wasn't clear, I'm worried about what happens in the
interim. The problem will be fixed in ACPICA 20051202, but we have at
least one, likely two stable kernels that will be tagged before that
ACPICA version hits the upstream kernel. We can hit the owner_id limit
fairly easily on a few development systems. How many stable kernels do
we want out in the wild with such a low owner_id limit? Bumping it up
to 64, while not ideal, is sufficient for our current usage, and I think
the patch is trivial enough that it could be included quickly. Thanks,

Alex

--
Alex Williamson HP Linux & Open Source Lab