From: heiser@ferrari.nmc.ed.ray.com (Bill Heiser)
Subject: 3/480 4.0.3 CRASH!
Organization: Equipment Division, Raytheon Company
Distribution: usa
Date: Wed, 15 Apr 92 16:21:06 GMT

We saw the following error yesterday on one of our 3/480's yesterday.
Sun support isn't able to escalate the call to investigate it for us 
because 4.0.3 is past "end of life".  Anyone seen this error and know
what might cause it and/or how to avoid it?

Actually there was another error we saw today that I will include in
case they are related.

The machine in question is a 3/480 (68030) with 32mb of ECC memory.  We
have the "ECC memory patch" and "NFS file corruption patch tape version 2.0"
installed.  It has been in this configuration for a couple of years without
any problems (like this one anyway).

Thanks in advance.
Bill

----------

This particular problem showed up yesterday.  After the reboot, the
machine seemed to "hang" several times later in the day, requiring forced
reboots.  

Apr 14 10:35:53 tdw205 vmunix: automount:
Apr 14 10:35:53 tdw205 vmunix: trap address 0x8, pid 137, pc = f8059f7a, sr = 2104, stkfmt a, root ptr 1a83400
Apr 14 10:35:53 tdw205 vmunix: Bus Error Reg 0,MMU Status Reg 403
Apr 14 10:35:53 tdw205 vmunix: data fault address 0 faultc 0 faultb 0 dfault 1 rw 0 size 0 fcode 5
Apr 14 10:35:53 tdw205 vmunix: KERNEL MODE
Apr 14 10:35:53 tdw205 vmunix: pte 0
Apr 14 10:35:53 tdw205 vmunix: D0-D7  17f 0 22 0 0 0 0 0
Apr 14 10:35:53 tdw205 vmunix: A0-A7  6000 4 ffed4e54 f80f6990 f80a9b60 f80f7608 f80a9aa8 f80a9a94
Apr 14 10:35:53 tdw205 vmunix: Begin traceback...fp = f80a9aa8, sp = f80a9a94
Apr 14 10:35:53 tdw205 vmunix: Called from f801c588, fp=f80a9abc, args=0 6000 0
f80a9af8
Apr 14 10:35:53 tdw205 vmunix: Called from f80a53d4, fp=f80a9af8, args=6000 f80f7608 2aa 0
Apr 14 10:35:53 tdw205 vmunix: Called from f80a6a02, fp=f80a9b20, args=f80f7608
0 ff286350 ff286350
Apr 14 10:35:53 tdw205 vmunix: Called from f80a6854, fp=f80a9ca0, args=f80f7608
f80a9b60 f8152100 0
Apr 14 10:35:53 tdw205 vmunix: Called from f80a662a, fp=f80a9cc4, args=f80f7608
ff286350 0 f80a65d0
Apr 14 10:35:53 tdw205 vmunix: Called from f801f512, fp=f80a9ce8, args=0 0 2000
0
Apr 14 10:35:53 tdw205 vmunix: Called from f8024380, fp=f80a9d04, args=2000 ffed4000 ffffd0a8 f815bf18
Apr 14 10:35:53 tdw205 vmunix: Called from f800493e, fp=ffffd01c, args=0 7ffffc00 0 7ffffc00
Apr 14 10:35:53 tdw205 vmunix: End traceback...
Apr 14 10:35:53 tdw205 vmunix: panic: Bus error
Apr 14 10:35:53 tdw205 vmunix: zs3: silo overflow
Apr 14 10:35:53 tdw205 vmunix: syncing file systems... [7] [6] [2] done
Apr 14 10:35:53 tdw205 vmunix:
Apr 14 10:35:53 tdw205 vmunix: dumping to vp ff005b28, offset 192797
Apr 14 10:35:53 tdw205 vmunix: 4093 total pages, dump succeeded
Apr 14 10:35:53 tdw205 vmunix: rebooting...
Apr 14 10:35:53 tdw205 vmunix: SunOS Release 4.0.3 (TDW205SMT2) #1: Wed May 16 07:34:31 EDT 1990
Apr 14 10:35:53 tdw205 vmunix: Copyright (c) 1989 by Sun Microsystems, Inc.
Apr 14 10:35:53 tdw205 vmunix: mem = 32768K (0x2000000)
Apr 14 10:35:53 tdw205 vmunix: avail mem = 31940608

-----

This particular panic we never saw until recently when we installed 
the latest (007 version) rpc.lockd patch.  We have backed out all of
the associated files (we have double-checked this against another system),
and are running our old kernel (definitely)!!!  This particular problem
seems to take a while to manifest itself.

Apr 15 10:32:16 tdw205 vmunix: spurious level 3 interrupt
Apr 15 11:00:58 tdw205 vmunix: kmem_free: free block overlap ff28a96c+426 over ff28aa12
Apr 15 11:00:58 tdw205 vmunix: panic: kmem_free: free block overlap
Apr 15 11:00:58 tdw205 vmunix: syncing file systems... [17] [16] [11] [5] done
Apr 15 11:00:58 tdw205 vmunix:



-- 
* Happiness is a hot boiled lobster with drawn butter, a side dish of hot     *
* fresh steamers with melted butter & a hot corn on the cob with butter & salt*
Work: heiser@sud509.ed.ray.com
Home: bill@unixland.natick.ma.us  Public Access Unix/USENET 508-655-3848
Newsgroups: comp.sys.sun.admin,comp.windows.open-look