Date: Tue, 5 Jun 2007 12:49:37 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: Possible ACPI relared panic with Tyan S2720 Message-ID: <20070605094937.GU2268@deviant.kiev.zoral.com.ua> In-Reply-To: <46652286.2040006@root.org> References: <20070604183419.GA73268@peter.osted.lan> <46646BD3.5080900@root.org> <20070605043758.GA99622@peter.osted.lan> <46652286.2040006@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070605094937.GU2268>