Dear Managers,
Thanks to all of the responses, One of the following two actions
solved my problem, both of which are vague, but may be able to point
someone else in the right direction.
The original problem was a Sparc 1+ running SunOS 4.1.3 would ritually
crash every afternoon with the message :
PANIC: Spec_Badop
We have an ethernet network with NFS-Share and Beame & Whiteside NFS
on our Mac's and PC's, respectively. The Sparc is acting as a server
to the PC's and Mac's.
The solution was either:
a) Cleaning out the network trash folders that are created by
NFS-Share. Sometimes these folders contained trash that would not
delete on the Mac's when the volume is mounted. The trash is still
there and the files i found were pretty old (Mar 1993). I have a
feeling that some power users on the Mac side may have been trying to
find exotic ways to delete the material and could have caused
filesystem problems with their methods(?).
b) Resolving a conflict between two PC's that seemed to crash and lock
up after an inconsistent period of time on the network. One of the
machines was wiped clean and re-configured from the ground-up, and
then both machines worked fine. The re-configuring came after
EXTENSIVE troubleshooting sessions that showed no apparent conflict
with IP numbers or ethernet addresses(rare), etc. The re-configured
PC was heavily modified by the user, and there was no telling what
could have been debugged/hacked that didn't show up during normal
investigation.
I did both of these tasks near-simultaneously, and the crash problem
never re-surfaced. Personally, i side with 'a' being the cause, but I
can't be sure. Reasosns being that I have had similar problems with
the Mac's causing this type of server crash with throwing out trash in
the past, and, the PC-PC confilct surfaced 3-4 days before the crashes
started taking place.
Gilbert Young
gyoung@ccmail.crc.com
P.S. Below are the responses, of which i am greatful for!
NOTE: Special thanks to Nate Itkin, his response (at the end) is a
mouthful! Thanks for the efforts, Nate!
**********************************************************************
**********************************************************************
Hi
This sounds like a memory problem but i am not 200% sure about this.
Try to change the PROM value so that the system will do a memory check
on all 16 Meg not just 1Meg which is the default at boot time, see if
it reports a problem. GLuck.
HarisH Malneedi
Goldman Sachs, NY
(harishm@pcsdnfs1.eq.gs.com)
**********************************************************************
**********************************************************************
Hi,
>
> panic: spec_badop.
>
> What does this mean? Is it hardware or software.
No real answer to this one, but I will try to narrow it down (I
hope!).
I think it is a problem with one of your PCNFS clients, since having a
browse through some Sun stuff I see that they discribe it as a
"4.1.x NFS server will panic whilst processing a bogus request from a
NFS client"
OK, dose not help much, but I thought I would give it a try.
Good hunting!
Andrew Watkins
**********************************************************************
**********************************************************************
Based on what I can gleen from kernel disassembly with adb:
_spec_badop: save %sp, -0x60, %sp
sethi %hi(0xf8154000), %o0
call _panic
or %o0, 0x148, %o0
ret
restore
A tour of /sys/`arch -k`/OBJ/spec_*.o with nm gives:
/sys/sun4c/OBJ/spec_vfsops.o:
00000004 C _allproc
00000004 C _bclnlist
U _bdevvp
..
00000000 t _spec_badop
The spec_badop function basically does nothing but call panic and it's
defined in spec_vfsops.o. I would say this routine is probably
plugged into the vfsops structure for spec file system operations
which should never happen.
I would look carefully for configuration bogons with special file
systems tmpfs and swap. Good luck.
--
- Nate Itkin
- Portland Technology Development, Intel Corporation Aloha,
Oregon - E-mail: Nate-Itkin@ptdcs2.intel.com
**********************************************************************
**********************************************************************
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:02 CDT