From nobody@FreeBSD.org  Mon Feb 11 01:35:45 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 5B5A516A41B
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 11 Feb 2008 01:35:45 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 1365E13C442
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 11 Feb 2008 01:35:45 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m1B1XW2I026121
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 11 Feb 2008 01:33:32 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m1B1XWtJ026120;
	Mon, 11 Feb 2008 01:33:32 GMT
	(envelope-from nobody)
Message-Id: <200802110133.m1B1XWtJ026120@www.freebsd.org>
Date: Mon, 11 Feb 2008 01:33:32 GMT
From: Arthur Hartwig <arthur.hartwig@nokia.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: acpi_alloc_wakeup_handler: can't alloc wake memory
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         120515
>Category:       kern
>Synopsis:       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc wake memory
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-acpi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 11 01:40:02 UTC 2008
>Closed-Date:    Sun Dec 05 15:07:22 UTC 2010
>Last-Modified:  Sun Dec 05 15:07:22 UTC 2010
>Originator:     Arthur Hartwig
>Release:        6.3
>Organization:
Nokia
>Environment:
>Description:
The following message appears during startup:

acpi_alloc_wakeup_handler: can't alloc wake memory

Investigation shows the problem to be that there is no free memory with
sufficiently low physical address.

(This message has not been seen during startup of a generic kernel but
Nokia has applied a number of tweaks to significantly increase the kernel
virtual address including setting KERNBASE to 0x60000000).


>How-To-Repeat:

>Fix:
In vm/vm_page.c function vm_page_startup()loops over the available memory
blocks in order of increasing address calling vm_pageq_add_new_page(pa)
which calls vm_pageq_enqueue() which adds the page to the tail of the
appropriate vm_pages_queue queue. Thus on return from vm_page_startup()
the vm_pages_queue queues are ordered by increasing physical address.
Removal from these queues is from the queue head so the pages with lowest
physical address are allocated first.

The following change steps through the available memory blocks in order
of decreasing physical address (allocating pages to the queues in order
of increasing address) thus relegating the pages with low physical address
to the end of the queues and increasing the likelihood that suitable
pages will be found to meet the request of acpi_alloc_wakeup_handler().

*** 329,342 ****

        /*
         * Construct the free queue(s) in descending order (by physical
!        * address) so that the first 16MB of physical memory is allocated
         * last rather than first.  On large-memory machines, this avoids
         * the exhaustion of low physical memory before isa_dma_init has run.
         */
        cnt.v_page_count = 0;
        cnt.v_free_count = 0;
        list = getenv("vm.blacklist");
!       for (i = 0; phys_avail[i + 1] && npages > 0; i += 2) {
                pa = phys_avail[i];
                last_pa = phys_avail[i + 1];
                while (pa < last_pa && npages-- > 0) {
--- 330,344 ----

        /*
         * Construct the free queue(s) in descending order (by physical
!        * address) of base address of memory block so that the first
!        * 16MB of physical memory is allocated
         * last rather than first.  On large-memory machines, this avoids
         * the exhaustion of low physical memory before isa_dma_init has run.
         */
        cnt.v_page_count = 0;
        cnt.v_free_count = 0;
        list = getenv("vm.blacklist");
!       for (i = nblocks*2-2; i >= 0 && npages > 0; i -= 2) {
                pa = phys_avail[i];
                last_pa = phys_avail[i + 1];
                while (pa < last_pa && npages-- > 0) {


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi 
Responsible-Changed-By: remko 
Responsible-Changed-When: Mon Feb 11 06:43:19 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=120515 

From: Dan Lukes <dan@obluda.cz>
To: bug-followup@FreeBSD.org, arthur.hartwig@nokia.com
Cc:  
Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't
 alloc wake memory
Date: Mon, 11 Feb 2008 16:34:58 +0100

 Duplicate of kern/119356 but with different fix

From: Arthur Hartwig <Arthur.Hartwig@nokia.com>
To: ext Dan Lukes <dan@obluda.cz>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't
 alloc wake memory
Date: Wed, 13 Feb 2008 16:58:47 +1000

 ext Dan Lukes wrote:
 > Duplicate of kern/119356 but with different fix
 G'day Dan,
     Thanks for the pointer to the other PR.
 
 Based on the comments preceding the code I suggested be changed, I 
 suspect the the vm subsystem originally added pages to the head of the 
 free queues and removed them from the head of the free queues so that 
 the first pages added to the free queues were the last actually 
 allocated. Unfortunately this scheme has the undesirable consequence 
 that once the system is up and running a free page is more likely to be 
 reused soon thus obliterating information that might be useful to 
 someone dredging a crash dump for clues why a panic occurred. But I 
 haven't done the research.
 
 Your proposed change in PR 119356 looks OK to me apart from the 
 disadvantages you mention AND it doesn't help anything else that might 
 need to allocate memory at low physical addresses (not that I know of 
 anything).
 
 Arthur
 

From: Alan Cox <alc@cs.rice.edu>
To: bug-followup@FreeBSD.org,  arthur.hartwig@nokia.com
Cc:  
Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't
 alloc wake memory
Date: Sat, 21 Jun 2008 01:28:29 -0500

 This patch does not apply to HEAD or RELENG_7 in two senses of "apply".  
 The code affected by the patch has changed and so the patch will not 
 mechanically apply.  More importantly, the new physical memory allocator 
 in HEAD and RELENG_7 already addresses this problem in a systematic way.
 
 I see no reason not to apply this patch to RELENG_6.
 
 Alan
 

From: Dan Lukes <dan@obluda.cz>
To: Alan Cox <alc@cs.rice.edu>
Cc: freebsd-acpi@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't
 alloc wake memory
Date: Sun, 22 Jun 2008 14:49:02 +0200

 Alan Cox wrote:
 >  new physical memory allocator in HEAD and RELENG_7 already addresses this problem in a systematic way.
 >  
 >  I see no reason not to apply this patch to RELENG_6.
 
 	At the first, I analyzed problem for myself. My 6.x based instalations 
 affected by the problem are hacked already as I decide not to wait 
 several months for next release.
 
 	Well, I offered the analysis and hack to the public also.
 
 	To apply it into RELENG_6 or not apply it into RELENG_6 - it is 
 commiters decision. I have no problem with either decision.
 
 					Dan

From: vwe
Date: Fri, 17 Oct 2008 16:22:32 +0200

 According to Joerg, one or two pages should be allocated at module load
 time (boot-time). This should be sufficient.

From: John Baldwin <jhb@FreeBSD.org>
To: bug-followup@FreeBSD.org, arthur.hartwig@nokia.com
Cc:  
Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't
 alloc wake memory
Date: Wed, 02 Jun 2010 09:08:14 -0400

 Can you verify that this issue is resolved in 7.2 or later?
 
 -- 
 John Baldwin
State-Changed-From-To: open->closed 
State-Changed-By: avg 
State-Changed-When: Sun Dec 5 15:06:38 UTC 2010 
State-Changed-Why:  
Based on lack of recent feedback I conclude that the problem 
is solved in currently supported versions. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=120515 
>Unformatted:
