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.orgReceived 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