Date: Tue, 5 Jun 2007 15:26:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Peter Holm <peter@holm.cc> Cc: freebsd-acpi@freebsd.org Subject: Re: Possible ACPI relared panic with Tyan S2720 Message-ID: <200706051526.48269.jhb@freebsd.org> In-Reply-To: <20070605043758.GA99622@peter.osted.lan> References: <20070604183419.GA73268@peter.osted.lan> <46646BD3.5080900@root.org> <20070605043758.GA99622@peter.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 05 June 2007 12:37:58 am Peter Holm wrote: > On Mon, Jun 04, 2007 at 12:45:23PM -0700, Nate Lawson wrote: > > Peter Holm wrote: > > > I have a panic that comes and go. Kostik has helped me narrow the > > > problem down to AcpiOsWritePort(). > > > > > > It is not a problem for me, as there are various was to work around > > > it. > > > > > > More info can be found here: http://people.freebsd.org/~pho/acpi.html > > > > Thanks for all your debugging effort. > > > > You are welcome :-) > > > 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 Is name a malloc'd variable? That might explain the low address. Perhaps we aren't properly respecting the top of high memory stuff from the BIOS when using SMAP? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706051526.48269.jhb>