perry@cs.odu.edu (Perry Lovill) (11/06/90)
[ Nettiquitte Note: Please e-mail (rather than post) Replies where possible. ]
Our file server has been crashing with the above error message serveral
times a day for the last week-and-a-half; and I am now at a complete loss
(short of replacing the entire File Server) as to how to solve the problem.
I no longer have the manual for the 386 motherboard, and have no diagnostics
particular to this system. I downloaded the RAMTST30 program from the SIMTEL20
archives and ran it all night, but it never discovered any bad memory chips.
There have been no hardware or software changes to the system in months, and
it was running fine up until the week before last; so I am inclined to
believe it is a hardware problem of some sort, but w/o diagnostics to pin-
point it, I am at a loss. I have even tried taking out each memory chip
and re-seating them (they are all on the motherboard) and each expansion
card too.
If anyone has ideas, suggestions, directions to other resources, the
information would be greatly appreciated. The (hopefully relevant) details
are as follows:
- 386 8/25Mhz CPU, 1 mono/lpt, 2 com's, 1 1.2Mb fl, 4Mb RAM=18 1Mbit DRAM's
- Future Domain SCSI host adapter Model 750
- SCSI CDC 94171-9 WrenIV (~300Mb) hard drive
- SCSI CIPHER QIC-format (~250Mb) tape drive
- American Megatrends Inc. (AMI) 386-BIOS
- APS Corp. UPS system Model 520ES
- Novell Advanced Netware 286 V2.12 8/12/88
As usual, ADVthanksANCE,
Perry
--
--
Perry Lovill, Old Dominion Univ., Norfolk, VA, USA (PROSOFT Inc., VA Beach, VA)
[perry@cs.odu.edu] | [...!uunet!xanth!perry] | [...!uunet!xanth!prose!root]mckimg@bronze.ucs.indiana.edu (Geoffrey McKim) (11/07/90)
In article <1990Nov6.155258.8676@cs.odu.edu> perry@cs.odu.edu (Perry Lovill) writes: >[ Nettiquitte Note: Please e-mail (rather than post) Replies where possible. ] > I apologize for taking up bandwidth for this seemingly trivial issue, but I fail to see how it is "good Nettiquitte" to reply via email rather than post a response that might be of interest to several of us. Is the purpose of USENET free private consulting, or is it dissemination of potentially useful material to as wide a base as possible of interested people? Thanks for the time, and again, I apologize for the breach of "Nettiquette". ========================================================================= Geoffrey W. McKim Internet: mckimg@ucs.indiana.edu UCS Networks/LAN Group BITNET: mckimg@iuamber Indiana University Bloomington "Not speaking for IU or UCS, only 855-4643 for me..." =========================================================================
kenh@techbook.com (Ken Haynes) (11/07/90)
In article <1990Nov6.155258.8676@cs.odu.edu> perry@cs.odu.edu (Perry Lovill) writes: > >Our file server has been crashing with the above error message serveral >times a day for the last week-and-a-half; and I am now at a complete loss >(short of replacing the entire File Server) as to how to solve the problem. Instead of just reseating the chips, have you tried to replace them? "other" hardware going flakey can also cause an NMI interrupt, check the disk drives and LAN card if you have diagnostics for them. Are there devices on the LPT and COM ports? If not, can they be disabled? When you performed your netgen did you tell the linker there were LPT and COM ports in the system? Have you added any new protocols to the wire lately? Can your vendor help in any way? KEN -- ****************************************************************************** Network Support Services: UUCP: {nosun, sequent, tessi} kenh@techbook
rick@lrark.UUCP (Rick Mobley) (11/10/90)
In article <1990Nov7.140157.9904@techbook.com> kenh@techbook.com (Ken Haynes) writes: >In article <1990Nov6.155258.8676@cs.odu.edu> perry@cs.odu.edu (Perry Lovill) writes: >> >>Our file server has been crashing with the above error message serveral >>times a day for the last week-and-a-half; and I am now at a complete loss >>(short of replacing the entire File Server) as to how to solve the problem. > Are you running any Value Added Processes (VAPs)? I had this with the MAC VAP and found that I was short of memory when all the processes got busy. -- rick@lrark.UUCP * bang path --> uunet!ddi1!lrark!rick * Ricky Mobley * LRTUG (501) 224-9454 * 1800 Sanford Dr. #4 * GEnie Unix RT SysOp address LRARK * Little Rock, AR 72207 * WB5FDP.AR.USA.NA wb5fdp.ampr.org *
douglas@wybbs.mi.org (Douglas Mason) (11/14/90)
Something you didn't mention was what type of topology you are running --
we had some simular problems under Netware 386 3.1 with some ethernet cards
we were running, which caused all kinds of memory pool and buffer problems,
coming from almost mysterious locations, memory dumps, etc.
Don't know if anyone found this out quite like I did, but I found an error
that apparently Novell is "working on", but as much as I try to follow the
news, hasn't spread around too much.
On Netware 386 ver 3.1, I was using FILER to completely kill some Open
Systems directories that were going to be re-transferred (via Novell's
UPGRADE utility).
I went in to "directory contents" and selected an entire directory to delete.
FILER just sat there, then about 3 seconds later, the fileserver crashed in
a big way. I knew that I was the only person on the server at the time, but
hoping for the best, I re-booted the server, and tried again. Same thing
happened.
After a few calls I learned that Netware 386 v3.1 has a bug that when you
try to deleted a directory structure (using FILER, Directory Master, etc)
with more than 8 trustees assigned to it, the server crashes. Quite a
major bug.
Also, we are running 2 Micropolis 630meg (formatted) ESDI drives in it and
I set the block size for the volumes as 4k blocks. When I use Norton,
Directory Master or any other utilities, it seems to think that there are
8k blocks out there. Who is right? I know that generally non-Novell
utilities are not too good at looking at volume setups like that, but
many other strange things with large files have been happening and I
wondered if there was any sure way of checking the block size.
Other than that, Netware 386 seems to be pretty damn nice. Due to financial
conditions, we tried to run 3.1 on an Acer 386/20 with 4 megs of ram. With
that amount of memory, we couldn't use 4k block sizes on 1.3 gigs of storage
and successfully mount the volumes. Now with 8 megs we can mount the volumes,
but....
I welcome and comments/threats/suggestions....!
| Douglas Mason | System Administrator | ITM Corporation | Grand Rapids, Mich |