Re: panic: Memory modified after free

From: Doug White <dwhite_at_gumbysoft.com>
Date: Sat, 4 Feb 2006 21:51:32 -0800 (PST)
Sorry for the late response on this, but I just debugged similar issues on
a Tyan S2892. The problem there was that the system would panic in unusual
places under load. The root cause was that the BIOS was not down-clocking
the DIMM speeds under high-load situations (e.g, all DIMM slots
populated), which caused random memory corruption. Updating to BIOS v2.00
fixed the problem.

Make sure you are running BIOS v3.04 or later on your S2882.  The BIOS
download for that motherboard is:

http://www.tyan.com/support/html/b_s2882.html

The other option is to remove DIMMs from the system.

On Tue, 31 Jan 2006, Steve Kargl wrote:

> On Tue, Jan 31, 2006 at 05:01:57PM -0800, Steve Kargl wrote:
> > On Tue, Jan 31, 2006 at 01:22:09PM -0800, Steve Kargl wrote:
> > > The system is a dual proc Tyan K8S Pro with 12 GB of memory.
> > > The kernel is UP.  This was recorded by hand. I have the crash dump.
> > >
> > > Memory modified after free 0xffffff02505e0c00(504) val=deadc0dd _at_
> > > 0xffffff02505e0cd0
> > >
> >
> > Thing are looking positively horrid.  A kernel from a cvsup with
> > a date=2006.01.25.00.00.00 appears to work fine.  A kernel from with
> > date=2006.01.27.00.00.00 dies with
> >
> > dev_relthread() at dev_relthread+0x2e
> > devfs_close() at devfs_close+0x1b6
> > VOP_CLOSE_APV() at VOP_CLOSE_APV+0x74
> > vn_close() at vn_close+0x8d
> > vn_closefile() at vn_closefile+0x5a
> > fdrop_locked() at fdrop_locked+0xa1
> > closef() at closef+0x35f
> > fdfree() at fdfree+0x513
> > exit1() at exit1+0x360
> > sys_exit() 	at sys_exit+0xe
> >
>
> a 2006.01.26.12.00.00.00 kernel dies a similar death.
> Unfortnately, this panic took out a portion of /usr/include
> and /usr/src.  I can't prove it yet, but I think the
> pts code may be the trigger.
>
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org
Received on Sun Feb 05 2006 - 04:51:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC