From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 5 10:14:12 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 2CB3F16A41F for ; Tue, 5 Jun 2007 10:14:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id B623A13C457 for ; Tue, 5 Jun 2007 10:14:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HvVfk-000CWI-Cw for freebsd-acpi@freebsd.org; Tue, 05 Jun 2007 12:49:55 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l559nc0E013669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 12:49:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l559ncQQ019976; Tue, 5 Jun 2007 12:49:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l559nbu3019975; Tue, 5 Jun 2007 12:49:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Jun 2007 12:49:37 +0300 From: Kostik Belousov To: Nate Lawson Message-ID: <20070605094937.GU2268@deviant.kiev.zoral.com.ua> References: <20070604183419.GA73268@peter.osted.lan> <46646BD3.5080900@root.org> <20070605043758.GA99622@peter.osted.lan> <46652286.2040006@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iskw6J4cuOvZ6IVF" Content-Disposition: inline In-Reply-To: <46652286.2040006@root.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 49b91432ac2f6f50aab85e53d3752740 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1118 [June 05 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release 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 10:14:12 -0000 --iskw6J4cuOvZ6IVF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 05, 2007 at 01:44:54AM -0700, Nate Lawson wrote: > 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=3D01 base=3D0000000000000000 len=3D000000000009fc00 > >>> SMAP type=3D02 base=3D000000000009fc00 len=3D0000000000000400 > >>> SMAP type=3D02 base=3D00000000000e0000 len=3D0000000000020000 > >>> SMAP type=3D01 base=3D0000000000100000 len=3D000000003fef0000 > >>> SMAP type=3D03 base=3D000000003fff0000 len=3D000000000000f000 > >>> SMAP type=3D04 base=3D000000003ffff000 len=3D0000000000001000 > >>> SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000100000 > >>> SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 > >>> SMAP type=3D02 base=3D00000000fff80000 len=3D0000000000080000 > >> 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. > >> > >=20 > > If I did it right (I used a vtophys() on the address): > >=20 > > Address of mod->name(if_tun): 0xc3eed5ec, phys: 0x985ec >=20 > 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. >=20 > 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? It looks somewhat fishy. Kernel shall be loaded fully above 1st Mb (at 4Mb, in fact). The overwritten location belongs to the kernel data segment, and shall be not loaded into the low 1Mb. --iskw6J4cuOvZ6IVF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGZTGxC3+MBN1Mb4gRAqaHAKCCJ1EO/h1ib5zju+hlgDiO2DSLnwCgho+Z SSL0lzZRfj5GarJ8hkySXFI= =AAvy -----END PGP SIGNATURE----- --iskw6J4cuOvZ6IVF--