Possible ACPI relared panic with Tyan S2720

[Kostik Belousov]

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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20070605/6d0c6d02/attachment.pgp