SUMMARY: Spec_Badop crash

Date: Tue May 24 1994 - 15:16:14 CDT

     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
     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
     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!
     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
> 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
     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
     A tour of /sys/`arch -k`/OBJ/spec_*.o with nm gives:
     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:

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:02 CDT