From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 13 07:30:05 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7437016A421 for ; Wed, 13 Feb 2008 07:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E485213C458 for ; Wed, 13 Feb 2008 07:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1D7U4qi030468 for ; Wed, 13 Feb 2008 07:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1D7U4Ow030463; Wed, 13 Feb 2008 07:30:04 GMT (envelope-from gnats) Date: Wed, 13 Feb 2008 07:30:04 GMT Message-Id: <200802130730.m1D7U4Ow030463@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Arthur Hartwig Cc: Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc wake memory X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arthur Hartwig List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2008 07:30:05 -0000 The following reply was made to PR kern/120515; it has been noted by GNATS. From: Arthur Hartwig To: ext Dan Lukes 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