All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
To: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Subject: Re: [PATCH] take2: enable acpi_os_allocate() to allocate larger memory
Date: Tue, 24 May 2005 20:38:58 +0900	[thread overview]
Message-ID: <42931252.8000400@jp.fujitsu.com> (raw)
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B300381628C-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>

Hi,

Thank you for the information.

Please note that the failure of reading /proc/acpi/dsdt is
just an example. I think there will be other cases that
acpi_os_allocate() needs to allocate memory larger than the
maximum allocation size of kmalloc(). For example, custom
DSDT cannot be loaded on my machine without this patch. So
I think we need this patch even if /proc/acpi/dsdt will be
removed in the future.

Thanks,
Kenji Kaneshige


Brown, Len wrote:
> My personal preference is to delete /proc/acpi/dsdt
> rather than complicate other code to support a feature
> that shouldn't exist.
> 
> We've got an updated user-space utility that can read dsdt,
> multiple ssdt, etc -- should be available in an acpica release soon;
> replacing the current pmtools acpidmp.
> 
> -Len
> 
> 
>>-----Original Message-----
>>From: Kenji Kaneshige [mailto:kaneshige.kenji-+CUm20s59erQFUHtdCDX3A@public.gmane.org] 
>>Sent: Tuesday, May 24, 2005 4:28 AM
>>To: Brown, Len; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>Cc: Alan Cox
>>Subject: [PATCH] take2: enable acpi_os_allocate() to allocate 
>>larger memory
>>
>>Hi,
>>
>>Here is an updated patch to enable acpi_os_allocate() to allocate
>>larger memory. This patch is based on the feedback from Alan Cox
>>(Thank you!).
>>
>>Len, could you consider applying this patch?
>>
>>Thanks,
>>Kenji Kaneshige
>>
>>---
>>
>>I encountered the problem that I could not read /proc/acpi/dsdt on my
>>machine. It turned out that acpi_os_allocate() was failed to allocate
>>buffer. The DSDT on my machine was too large for acpi_os_allocate() to
>>allocate the buffer.
>>
>>Current acpi_os_allocate() interface is implemented by using kmalloc()
>>whose maximum allocation size is limited. So acpi_os_allocate() would
>>fail if larger size than maximum allocation size of kmalloc was
>>specified. I think this restriction should be removed.
>>
>>The following patch enables acpi_os_allocate() to allocate larger
>>memory.
>>
>>Signed-off-by: Kenji Kaneshige <kaneshige.kenji-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>
>>---
>>
>>linux-2.6.12-rc4-kanesige/drivers/acpi/osl.c |   12 ++++++++++--
>>1 files changed, 10 insertions(+), 2 deletions(-)
>>
>>diff -puN drivers/acpi/osl.c~fix_acpi_os_allocate drivers/acpi/osl.c
>>--- linux-2.6.12-rc4/drivers/acpi/osl.c~fix_acpi_os_allocate	
>>2005-05-24 16:32:51.000000000 +0900
>>+++ linux-2.6.12-rc4-kanesige/drivers/acpi/osl.c	
>>2005-05-24 16:34:25.000000000 +0900
>>@@ -37,6 +37,7 @@
>>#include <linux/delay.h>
>>#include <linux/workqueue.h>
>>#include <linux/nmi.h>
>>+#include <linux/vmalloc.h>
>>#include <acpi/acpi.h>
>>#include <asm/io.h>
>>#include <acpi/acpi_bus.h>
>>@@ -145,13 +146,20 @@ acpi_os_vprintf(const char *fmt, va_list
>>void *
>>acpi_os_allocate(acpi_size size)
>>{
>>-	return kmalloc(size, GFP_KERNEL);
>>+	void *ptr = kmalloc(size, 
>>GFP_KERNEL|__GFP_NORETRY|__GFP_NOWARN);
>>+	if (!ptr)
>>+		ptr = vmalloc(size);
>>+	return ptr;
>>}
>>
>>void
>>acpi_os_free(void *ptr)
>>{
>>-	kfree(ptr);
>>+	if (VMALLOC_START <= (unsigned long)ptr &&
>>+	    (unsigned long)ptr < VMALLOC_END)
>>+		vfree(ptr);
>>+	else
>>+		kfree(ptr);
>>}
>>EXPORT_SYMBOL(acpi_os_free);
>>
>>
>>_
>>
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click

  parent reply	other threads:[~2005-05-24 11:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-24  9:48 [PATCH] take2: enable acpi_os_allocate() to allocate larger memory Brown, Len
     [not found] ` <F7DC2337C7631D4386A2DF6E8FB22B300381628C-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2005-05-24 11:38   ` Kenji Kaneshige [this message]
     [not found]     ` <42931252.8000400-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2005-05-24 12:17       ` Stefan Seyfried
  -- strict thread matches above, loose matches on Subject: below --
2005-05-24  8:28 Kenji Kaneshige

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42931252.8000400@jp.fujitsu.com \
    --to=kaneshige.kenji-+cum20s59erqfuhtdcdx3a@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.