From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 5 08:45:25 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8899816A469 for ; Tue, 5 Jun 2007 08:45:25 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6C77713C447 for ; Tue, 5 Jun 2007 08:45:25 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 83958 invoked from network); 5 Jun 2007 08:45:27 -0000 Received: from udp166215uds.hawaiiantel.net (HELO ?192.168.1.44?) (nate-mail@72.234.230.74) by root.org with ESMTPA; 5 Jun 2007 08:45:27 -0000 Message-ID: <46652286.2040006@root.org> Date: Tue, 05 Jun 2007 01:44:54 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Peter Holm References: <20070604183419.GA73268@peter.osted.lan> <46646BD3.5080900@root.org> <20070605043758.GA99622@peter.osted.lan> In-Reply-To: <20070605043758.GA99622@peter.osted.lan> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Possible ACPI relared panic with Tyan S2720 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2007 08:45:25 -0000 Peter Holm wrote: > On Mon, Jun 04, 2007 at 12:45:23PM -0700, Nate Lawson wrote: >> This is a really confusing issue. All the trace you have shows is that >> it occurs while transitioning the system from legacy to ACPI mode. >> Unfortunately, the details of what is going on are hidden in the BIOS >> since that write to a port triggers an SMI and the BIOS does the rest. >> >> However, it seems like the BIOS is reserving more memory, using memory >> it didn't reserve, or FreeBSD is using memory we shouldn't. John, any >> insight on the SMAP output? >> >>> SMAP type=01 base=0000000000000000 len=000000000009fc00 >>> SMAP type=02 base=000000000009fc00 len=0000000000000400 >>> SMAP type=02 base=00000000000e0000 len=0000000000020000 >>> SMAP type=01 base=0000000000100000 len=000000003fef0000 >>> SMAP type=03 base=000000003fff0000 len=000000000000f000 >>> SMAP type=04 base=000000003ffff000 len=0000000000001000 >>> SMAP type=02 base=00000000fec00000 len=0000000000100000 >>> SMAP type=02 base=00000000fee00000 len=0000000000001000 >>> SMAP type=02 base=00000000fff80000 len=0000000000080000 >> Peter, can you figure out what phys address is getting overwritten? >> Seems like it's the loader that sets up the module list and the loader's >> allocator may be using RAM it shouldn't. >> > > If I did it right (I used a vtophys() on the address): > > Address of mod->name(if_tun): 0xc3eed5ec, phys: 0x985ec So it's somewhere near 620K and the first region goes to 640K - 1 K. The last 1 K is type 2 (reserved). Nothing seems to show why switching to acpi mode results in an overwrite of data at 620K. I'm not sure where to look. There should be some way to write a guard pattern to that area but I'll have to think about it a bit first. Can you see if a BIOS update is available and try it out? What about seeing if you can pre-alloc (by hacking loader's SMAP code to reserve more of the first 640 K) and writing a pattern there, then verifying it at various points during boot to be sure we know exactly where the BIOS is writing? -- Nate