[comp.sys.novell] HELP: NW3.1 ABEND during heavy disk writes

medici@elbereth.rutgers.edu (Mark Medici) (02/21/91)

Greetings.

I'm having some chronic problems with NetWare/386 3.10a that I'm look-
ing for some help with.  Of course, I've already RTFM, and can't find
anything related.

I'm running NW386 3.10 rev A on some IBM PS/2 Model 80-041's.  These
are 16MHz 386 MCA boxes.  Each one has 14MB RAM, and two 300MB CORE
HC310 ESDI drives on a single IBM ESDI controller.  In two instances,
each drive is set-up as a unique NW volume (SYS and USR); but in one
case I have a 600MB multi-segment SYS: volume.  Two of the servers
have a IBM Token Ring Adapter II/A nic, and one has a Western Digital
EtherCard Plus/A.

The problem goes like this: On occasion, when performing a great deal
of disk writes on one of these servers, NW386 will ABEND with the
following message:

> 2/20/91  12:20pm: Error writing to file SASCORR.EXE, data stream 0
> Write requested by user !MEDICI on station 1
> File path was SYS:APPS\SAS.604\SASEXE\BASE\SASCORE.EXE
>
> System halted Wednesday, February 20, 1991  12:20:08 PM
> ABEND: NMI (Parity Error) Processor Exception
> Parity Error was generated by the system board
>   OS Version Novell NetWare 386 version 3.10 rev. A  6/13/90
>   Running Process AES Sleep Process
>
>     EA 12 07 00 4C 3F 07 00 00 00 00 78 56 34 12
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Of course, the username, station, path and filename will differ
depending on the circumstances.  Also, user !MEDICI (me) is a super-
visor equivalent account with full privs, there are no space
restrictions, an no existing files being overwritten.  All server
parameters are set for their defaults, and the following is this
system's AUTOEXEC.NCF:

>  file server name RUCS-PROTO
>  ipx internal net 80065315
>  load WDPULSSV slot=5 frame=ETHERNET_II
>  bind IPX to WDPLUSSV net=80035300
>  mount all
>  load PATCHMAN
>  load DELDIRFX
>  load FIXOPEN
>  load MONITOR
>  load REMOTE <password>
>  load RSPX
>  load PSERVER iml-proto-prn
>  spool 0 to PROTO-LJET3

Any and all suggestions will be greatly appreciated.  Though this
problem does not happen often, it is a recurring and repeatable source
of concern, and prevents me from performing server-to-server backups.

----------------------------------------------------------------------
          Mark Medici/SysProg3 * Rutgers University Computing Services
          medici@elbereth.rutgers.edu * CIS: 75140,1440 * 908/932-2412
-- 
-----------------------------------------------------------------------
Mark Medici/SysProg3 * RUCS/User Services * medici@elbereth.rutgers.edu
-----------------------------------------------------------------------

overlord@walt.cc.utexas.edu (Lee Sharp) (02/21/91)

In article <Feb.20.14.15.40.1991.17201@elbereth.rutgers.edu> medici@elbereth.rutgers.edu (Mark Medici) writes:
>> Parity Error was generated by the system board
>>   OS Version Novell NetWare 386 version 3.10 rev. A  6/13/90
>>   Running Process AES Sleep Process
>Mark Medici/SysProg3 * RUCS/User Services * medici@elbereth.rutgers.edu
>-----------------------------------------------------------------------

This looks to me like some flaky ram on your system board, that's what usually
causes parity errors..

-Scott Hutchinson
Thomas Conrad Corp

medici@dorm.rutgers.edu (Mark Medici) (02/22/91)

overlord@walt.cc.utexas.edu (Lee Sharp) writes:
>In article <Feb.20.14.15.40.1991.17201@elbereth.rutgers.edu> medici@elbereth.rutgers.edu (Mark Medici) writes:
>>> Parity Error was generated by the system board
>>>   OS Version Novell NetWare 386 version 3.10 rev. A  6/13/90
>>>   Running Process AES Sleep Process
>>Mark Medici/SysProg3 * RUCS/User Services * medici@elbereth.rutgers.edu
>>-----------------------------------------------------------------------

>This looks to me like some flaky ram on your system board, that's what usually
>causes parity errors..

But on three (actually four -- I've also tried a swap spare) boxes?

Anyone know of a good RAM exerciser for PS/2 Model 80's (that wouldn't
take three months to test 14MB)?

-- 
-----------------------------------------------------------------------------
Mark Medici ** Systems Programmer III * Rutgers University Computing Services
medici@elbereth.rutgers.edu * medici@cancer.BITNET * !rutgers!elbereth!medici
My opinions are not necessarily my employers'. *Reality is context-sensitive.