Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jun 2007 15:21:13 +0200
From:      Peter Holm <peter@holm.cc>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: Possible ACPI relared panic with Tyan S2720
Message-ID:  <20070605132113.GA14976@peter.osted.lan>
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
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=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?
> 
I'm somewhat hesitant to update the BIOS on  my one and only SMP
test box.  The BIOS is date 7/10/02, so it *is* old, but has served
as a stress test box since August 2005.
-- 
Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070605132113.GA14976>