From owner-acpi-jp@jp.FreeBSD.org Fri Feb  8 15:22:25 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g186MPs51344;
	Fri, 8 Feb 2002 15:22:25 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.68.253])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g186MO651339
	for <acpi-jp@jp.FreeBSD.org>; Fri, 8 Feb 2002 15:22:24 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id PAA84742
	for <acpi-jp@jp.FreeBSD.org>; Fri, 8 Feb 2002 15:20:59 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Message-Id: <200202080620.PAA84742@shidahara1.planet.sci.kobe-u.ac.jp>
To: acpi-jp@jp.FreeBSD.org
In-reply-to: Your message of "Thu, 07 Feb 2002 14:44:37 GMT."
             <20020207144437.A42137@genius.tao.org.uk>
Date: Fri, 08 Feb 2002 15:20:59 +0900
From: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+011218
X-Sequence: acpi-jp 1574
Subject: [acpi-jp 1574] Re: acpi_alloc_wakeup_handler: unable to allocate wake memory
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: takawata@shidahara1.planet.sci.kobe-u.ac.jp

In message <20020207144437.A42137@genius.tao.org.uk>, Josef Karthauser :
>
>> I suspect the memory allocation failure is caused by the large memory
>> itself. Larger memory requires larger management area. So the memory
>> management subsystem may eat up the memory area which wakeup handler
>> should live in.
>
>Where should I look to get a fix for this?  It's only started
>happening recently - in previous version of ACPI there was no
>problem.

Probably this is caused by VM change.
Possible way to avoid it is putting wakeup handler into 0x800-0xfff area,
which is not used by Operating System and hardware.

Takanori Watanabe
<a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
Public Key</a>
Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 

