From owner-freebsd-stable@FreeBSD.ORG Fri Jan 18 20:31:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F13D16A477 for ; Fri, 18 Jan 2008 20:31:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 0E33C13C448 for ; Fri, 18 Jan 2008 20:31:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 228991234-1834499 for multiple; Fri, 18 Jan 2008 15:29:09 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id m0IKUbcH095533; Fri, 18 Jan 2008 15:30:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Pete French Date: Fri, 18 Jan 2008 13:25:44 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801181325.45016.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 18 Jan 2008 15:30:46 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5495/Fri Jan 18 12:03:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: panic: vm_fault: fault on nofualt entry, addr: 81423000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 20:31:02 -0000 On Friday 18 January 2008 01:02:04 pm Pete French wrote: > > So it appears to be dying here: > > > > (gdb) l *madt_probe+0x119 > > 0xc06e7c69 is in madt_probe (/usr/src/sys/i386/acpica/madt.c:241). > > 236 if (xsdt == NULL) { > > 237 if (bootverbose) > > 238 printf("MADT: Failed to map XSDT\n"); > > 239 return (ENXIO); > > 240 } > > 241 count = (xsdt->Length - sizeof(ACPI_TABLE_HEADER)) / > > 242 sizeof(UINT64); > > 243 for (i = 0; i < count; i++) > > 244 if (madt_probe_table(xsdt->TableOffsetEntry[i])) > > 245 break; > > Turns out that it isn't - it's in the other branch of the if using the > RSDT instead of the XSDT. Not sure why the debugger was giving > misleading information. I added prints to find out which path it was > taking and to print out some values after the line > "rsdt = madt_map_table(rsdp->RsdtPhysicalAddress, 1, ACPI_SIG_RSDT);" > > The value of rsdtl is 0x800e7610, but the value of rsdp->XsdtPhysicalAddress > is zero! So I guess that is where the panic is comming from. So where > now ? Is there an equivalent patch to the one you emailed > earlier for this branch of the if ? The patch would be the same, it tried to fix an issue where if the table is longer than the space we are borrowing to map things we could end up with problems. I.e. the changes weren't in the RSDT/XSDT path at all, but in the common code used to map tables. If you are using RSDT, then RsdtPhysicalAddress is what you care about rather than XsdtPhysicalAddress. -- John Baldwin