From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 22 13: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 3F06C16A41B for ; Tue, 22 Jan 2008 13: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 1F20F13C46B for ; Tue, 22 Jan 2008 13:30:05 +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 m0MDU4IC094942 for ; Tue, 22 Jan 2008 13: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 m0MDU49R094937; Tue, 22 Jan 2008 13:30:04 GMT (envelope-from gnats) Date: Tue, 22 Jan 2008 13:30:04 GMT Message-Id: <200801221330.m0MDU49R094937@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Pete French Cc: Subject: Re: kern/119716: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pete French List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 13:30:05 -0000 The following reply was made to PR kern/119716; it has been noted by GNATS. From: Pete French To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119716: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 Date: Tue, 22 Jan 2008 13:23:32 +0000 With the help of John Baldwin on freebsd-stable I traced this a bit closer. Inside madt_probe in /usr/src/sys/i386/acpica/madt.c the code is ttaking the second brank of the 'ifi' statement - i.e. the branch which is for non 2.0 systems. It successfully completes the madt_map_table call, but then crashes when ttrying to access the returned data. Printing out the value of rsdp->RsdtPhysicalAddress on the retrun gives 0x7fec7f40.