
--------------------------------------------------------------------
NOV-SCS1.DOC -- 19970613 -- Email thread on NetWare and SCSI devices
--------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Mon, 6 Jun 1994 10:05:00 -0700
From: "Craig Warford" <WARFORD@UTHSCSA.EDU>
Subject: Re: Just Say No to SCSI! (repost) - LONG!!

>> This has been true for a long time, but not because of Windows in the
>> slightest.
>
>Wrong.  It is *exactly* because of Windows.  SCSI works wonders on Unix
>workstations, and (I have been told) on Macs.  The problem is that
>Microsoft has not properly supported the SCSI interconnect.

I have also seen SCSI work wonders on Windows.  Even if it is 16-bit, the
throughput is nothing to sneeze at, and certainly more than any IDE I have
seen.

>> It generally helps to have a 32-bit SCSI adapter, instead of the standard
>> 16-bit adapter most commonly sold.  That way, you don't need a 32-to-16
>> conversion driver added.
>
>You obviously don't know what you are talking about.  In the first
>place, 32-bit disk access has nothing to do with the width of the
>data path.  The absence of 32-bit disk access for SCSI is crucial to
>my argument.  In the second place, until wide SCSI becomes available,
>the widest data path between the host adapter and the disk drive is
>16 bits, not 32.  So your comment about a 32-to-16 conversion driver
>is rubbish.  There is no such thing.  I suggest that you read the
>Windows 3.1 resource kit for an explanation of what 32-bit disk
>access is.

Sorry, in the midst of my re-edits, that came out wrong.  The portion
"driver added" was from something else.  The conversion, as we all know,
takes place elsewhere.  (In this case, I was referring to 16-bit slots on
the ISA bus, since EISA, VLB, PCI, and the rare occasional 32-bit ISA slot
all transfer data without doubling up.)  But with ISA bus, you can still get
a 32-bit SCSI adapter, and it does have something to do with how fast your
data is accessed.

>> >In particular, the market leader (Adaptec) does not supply these
>> >drivers.
>> No, but they supply the 32-bit adapters, we have some.
>
>Adaptec sells hardware that has a 32-bit data path between motherboard
>and host adapter:  EISA, VLBus, and (possibly) PCI.  It doesn't supply
>the 32-bit Windows drivers, also known as protected-mode drivers.
>(See two paragraphs above).

So, what you are saying is that since Adaptec hasn't written proper 32-bit
drivers for their own product, Microsoft wrote 16-bit drivers for someone
else's product.  I gotcha.  But I still wouldn't lay the blame for that one
on Microsoft.  I would lay it on the SCSI manufacturers for not providing
better support for their own products.  MS doesn't make money off the sale
of SCSI products.  It's a black hole for them, and it should be the SCSI
manufacturer's responsibility to sell their own product by providing their
own product's compatibility.

>Wrong again.  The best way to use your RAM is to put it on the
>motherboard, NOT on the disk controller.  It's faster access for the
>CPU, since it doesn't have to go off-board to access it.  Also,
>modern operating systems can share available RAM between virtual
>memory needs and user-initiated I/O.  SunOS has been doing this for
>years, and Windows NT does it too, with excellent results.  Let's
>hope Chicago does it too.  I'm not holding my breath.

I disagree.  The SCSI drive still needs its own cache for writes.  This
prevents the main CPU from having to waste time and resources while waiting
for the drive to write, speeding things up dramatically.  Of, course, you
can argue that DMA would clear this up, but again, I disagree.  You can't
access two areas of main memory at the same time.  Whereas, you can access
main memory and your controller's cache memory separately.  It's just plain
faster.  That's why IDEs now have caching controllers of their own.  If the
motherboard is a better place, why make a new card with a place for cache?

Is it possible that you were double-caching your information on your SCSI?
 Most (if not all) SCSI controllers have cache on the controller card now.
 If you were caching there AND and on the motherboard, you've probably
defeated yourself.

>You missed my point entirely.  The presence of another BIOS in the
>system complicates life for the user.  Other software and hardware in
>the system might have a conflict with the presence of another BIOS in
>the memory map of the computer.  The fact that the BIOS stays on the
>adapter card is irrelevant.  In fact, it's a shame that the BIOS stays
>on the card, because the software resident therein executes slowly.
>Two reasons for this:  first, because the code is in slow EPROM memory
>(usually) and second, it is off the motherboard.

Hmmm... I guess we could say that too many cooks spoil the broth.  Perhaps a
better focus would be to simply store a definitive ROM on every card, then
let the PC's BIOS read all the information in at boot up, giving it one
master control.  I believe that's a small part of the new Plug and Play
specs.  When that comes, this argument will be moot.

>> Agreed.  But this does not imply that IDE can deliver the same
performance
>> as SCSI, potentially.  It just ain't so.  I have IDE in my own personal
>> computer, and probably always will.  But for servers, there's no
substitute
>> for cached SCSI, not even PCI IDE.
>
>My original post did not deal with servers.  I'm concerned about SCSI
>under Microsoft Windows 3.1.  I hope you don't run Windows on your
>server.

OOF!  My apology again, I got a bit off topic.  (I don't run Win3.1 on my
servers, I run NT.  Incidentally, you should see the throughput from NT to
NT.  Our sniffer shows bandwidth util. up to 97% on an isolated segment!!!)

>> Microsoft isn't about to drop SCSI.  They know its value.  They know the
>> market of users it affects.  And if they don't write the drivers, chances
>> are the hardware vendor will.  That's the only way they can sell to that
>> particular group of users.
>
>Yes, yes, Microsoft will allow SCSI to run under Chicago.  The
>question is, will they support it *well*, so that it works fast.  I
>sure hope so.

Here again, I think the individual vendors have a responsibility to develop
their OWN products, not expect Microsoft to do it.  They're getting a lot of
"freebies," and expect someone who doesn't know their product as well as
they do to do the work.  In light of current "workgroup" trends, I think
it's important for the individual groups to do their own work, not expect
the project leader to do it for them.  He's already got his hands full.

>> I think it would be a good idea for people to learn more about the things
>> they consider buying before buying them.  Maybe people wouldn't get so
upset
>> about the problems they encounter, because they will know to avoid them
>> ahead of time.
>
>True.  And that's why I posted my original article.  I wanted to give
>people the information they need before they buy.

Thanks for the discussion.  It's certainly something for people to consider.
 I myself am sticking with IDE simply for "bang-for-buck" reasons.  (Or is
that "no-buck" reasons?)  If you test out the caching IDE controllers before
I do, let me know your results.

------------------------------

Date: Mon, 30 Oct 1995 08:20:34 -0800 (PST)
From: Virendra Rode <virendra@nexus.chapman.edu>
Subject: What are fast-wide SCSI-2, SCSI-3 and Ultra SCSI-3 (fwd)

FAST SCSI: There are 2 handshaking modes on the SCSI bus, used for
transfering data: ASYNCHRONOUS and SYNCHRONOUS.

ASYNCHRONOUS is a classic Req/Ack handshake.

SYNCHRONOUS is "sort of" Req/Ack, only it allows you to issue multiple
Req's before receiving Ack's (Kinda like implementing packet burst on netware)

SYNCHRONOUS transfers are approx 3 times faster than ASYNCHRONOUS.

Fast SCSI achivies 10 mbyes/sec on the A-cable and with wider paths of 16
and 32 bits can rise to 20 mbyes/sec and even 40 mbyes/sec. However by
the time the market starts demanding 40 mbyes/sec it is likely that the
effort to serialize the physical interface for SCSI-3 will attract
high-performnace SCSI users to the Fiber Channel

SCSI1 allowed asynchronous transfers at up to 1.5 Mbytes/sec and synchronous
transfers at up to 5.0 Mbytes/sec.

SCSI2 asynchronous transfer can run at up to 3.0 mbytes/sec and
synchronous transfers at up to 10.0 mbytes/sec. The term "FAST" is
generally applied to a SCSI device which can do applied to SCSI2 devices
since SCSI1 didn't have the timing margins that allow for FAST transfers.

Wide SCSI: may now transfer data at bus widths of 16 and 32 bits. Which
means synchronous transfers at up to 20 mbytes/sec and asynchronous
transfers at up to 3 mbytes/sec max.

ULTRA SCSI: at 8 bit data bus it will support 20 mbytes/sec and 16 bit
data bus it will support 40 mbytes/sec.

---

Is SYNCHRONOUS faster than ASYNCHRONOUS?

Asynchronous is faster on short cables, while synchronous is faster on
long cables. The reason has to do with the propagation delay of the cable.

------------------------------

Date: Fri, 24 Nov 1995 13:58:03 -0800
From: Virendra Rode <virendra@NEXUS.CHAPMAN.EDU>
Subject: Re: CDROM on NW3.11

On Fri, 24 Nov 1995, Mr. R. Coates wrote:
>So... if anyone out there DOES have a scsi cd-rom running on a 3.11
>server, would you care to enlighten me?

Roy,

Future Domain Corp. now Adaptec, Inc., has the CDROM.NLM on
their BBS by now it should be up on their ftp site which was specifically
written to support SCSI cd-roms under NetWare 3.11.

------------------------------

Date: Mon, 27 Nov 1995 03:55:14 GMT
From: Richard Strong <compudoc@GATE.NET>
Subject: Re: Media Dismount

>>A volume on our server is "deactivated due to media dismount". I got the
>>error from CONLOG. Does anyone know anything about how or why this
>>happens occasionally? The version of NW does not matter; it happens with
>>3.12, 4.02, 4.1.
>>
>>I have talked to several MCNE's, and most answers are could be due to a
>>ribbon cable, hard drive malfunction, host adapter board malfunction,
>>or motherboard malfunction. Does anyone have a little more detailed
>>analysis?
>
>If you figure it out, let me know.  It has happened to me ever since I've
>gone to 2 gig drives.

Ok here is where the fun starts. First search www.novell.com and find the
doc that explains that drive deactivation is the responsibilith of the
driver due to communication trouble with the drive. Maybe ribbon cable,
such as cheap cable, impedance mismatch, cable too close to fan, video,
or other noise generating device. Bad termination, unterminated end etc.

Review your controller card documentation. Two bus master controller
cards in same machine will require that the bios be turned off on all
but one.  Set IRQ's in accending order put lowest IRQ on SCSI card
who's bios is enabled and place this card in the lowest numbered
slot, timing comes into play on high speed buses. Try dropping back
to 5 meg per second instead of 10. Finally: does the mother board
support these new cards?

------------------------------

Date: Mon, 27 Nov 1995 19:35:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: SCSI CD-ROMs on servers

	I thought most people were aware that the SCSI implementation on
many CD-ROM drives is junk. That's why folks have big trouble when players
share a SCSI bus with a high performance disk drive: the player can't cope
and messes up the system.
	There are work arounds. One is if your SCSI controller has the
ability to set the negotiation sync/async and speed of sync on a per
target basis then for the CD-ROM turn off sync. Hope the player also
supports SCSI disconnect (get a request, disconnect from the bus to
free it, come back later with the results) else it freezes the bus for
long times. Frozen buses yield volume dismounts under NetWare.
	Another is to throttle what the SCSI controller asks of the disk
drive, in an attempt to reduce the overall traffic rate and help the player
poor sister. Turning down the max sync speed is the item here. 10MB/sec
can kill weak devices.
	Yet another is to acquire a dual channel SCSI controller and
separate good from less-good on different SCSI channels. Adaptec makes
them, and hence BusLogic, etc. That takes one slot. Dual boards take two
slots, but maybe it is worth it in your cases.
	It pays to purchase CD-ROM drives carefully. My very limited
experience in this area has yielded Toshiba as the player of choice for
SCSI compatibility. The cost of such units is not low, but the overall
cost for the system is less than adding another SCSI controller with a
less than good player. Many backup tape drives suffer as do CD-ROM players;
HP DAT units seem to be good in my experience and I run them full bore on
the SCSI bus. Archive/Conner DAT drives are good but can't take high
pressure on the bus.
	Not all disk drives are created equal in the SCSI dept. The surge
of demand, falling prices per MB, the rush to very large drives all combine
to push products out the door willy nilly. DOS/Windows users won't notice
glitches because those o/s' don't push the hardware at all. NetWare and Unix
push hard. Both prefer that caches in peripherals be turned OFF. A change
of disk drive ROM may be necessary to eliminate the worst bugs.
	Lastly, cables and termination count heavily with high performance
buses. The big fat round external cables should cost a lot, and not be the
thin cheap guys. Internal ribbon cables are perfect. Terminators vary, with
active terminators being the best. Termination must be done properly, as
with coax, by placing terminators at the extreme ends of the cable and no
where else. If in doubt swap terminator blocks (the external kind) and
triple check the jumpers on the SCSI peripherals. Supply terminator power
to the SCSI bus is my personal choice, as is turning on SCSI parity
everywhere. Some manuals are opaque or confusing on jumper settings; check
with the vendor in cases of doubt. Turning off cache may require a program,
as with large Seagate drives; there is no jumper to do that trick.
	I have declined to entertain connecting CD-ROM players directly to
NW servers. It's a bad experience. Instead I puchased a Microtest Discport
tiny box. It has two connectors: BNC/10-Base-T network and a rotten 25-pin
SCSI (with 25-pin Apple nightmare to Centronics converter cable). It talks
to the server and behaves as if it were mounted but it does not consume
memory for FAT etc blocks like a real disk drive. No user software needed.
Network traffic doubles (tiny box to server, server to user). Not cheap,
works well.
	Joe D.

------------------------------

Date: Thu, 14 Dec 1995 20:01:02 -0800
From: tracy pillsbury <tracy@TECH-REF.MV.COM>
Subject: SCSI Controllers and Netware Partitions

>What controllers build compatible Netware Partitions on scsi disks with
>NCR, Adaptec and others...

SCSI, Small Computer Systems Interface I/O systems are built around a set
of commands not at all unlike those designed for any other processor.
These commands set guidelines for how a disk is formatted, read and
maintained by the I.O subsystem.

The SCSI standard is, Like everything else, in a state of constant
improvement. Though in and of itself it is a standard, there are +/-
variances that are allowed. The firmware which is loaded on the SCSI
Interface reflects these enhancements. The firmware is written to
address a disk in by what is known as offsets. These are physical
locations on the disk that end up being sectors and blocks. Each firmware
developer has their own set of offsets and variances which, though
compliant with the SCSI standard, vary from developer to developer.

so, when you Low level a drive on an adaptech 2740 series controller
and then put it on a Bustech, chances are it will fail. It is not the
fault of the drive or the controller but more the lack of technological
consistency.

------------------------------

Date: Fri, 15 Dec 1995 06:00:00 CDT
From: Larry Dolinar <LARRYD@BLDG1.CROUTE.COM>
Subject: Re: SCSI controllers & Netware partitions.

|	It should be remarked that there is one glaring control which
|may be the cause of some apparent mismatches. That is "translating
|cylinders/heads/sectors" for DOS, or not. SCSI boards differ on their
|default setting and probably their translation scheme. NetWare does
|not want any translation occuring, yet curiously it seems to tolerate
|it when it appears (as happened to me by mistake). A sign of translation
|mismatch is unable to boot to DOS from it, but can boot and see the drive
|via a boot floppy.
|	Again, NetWare wants translation turned off. If the drive is set up
|with translation on then to turn off translation involves repartitioning
|and hence reloading everything.
|	Joe D.

Agreed.  Adaptec's FaxBack document 39150 (Q&A - 2940) makes mention of
this (presumably for the 2940W as well -- same driver):

Q: I am installing a Novel (sic) server with the AHA-2940.  Are there any
   changes that need to be made to the card before installing the server
   software?

A: Before installing any Novell software, check that the settings
   "Extended BIOS Translation for DOS Drives > 1 Gbyte" and "BIOS Support
   for More Than 2 Drives (MS-DOS(R) 5.0 and above)" in the "Advanced
   Configuration Options" of SCSI-Select are disabled.  Failure to disable
   both options will result in problems when trying to install the Novell
   software.

Strangely this is left out of the .TXT files accompanying NW31X.exe,
their "latest" driver set at their ftp site.

What sort of problems is left to the student to discover, I guess.  What
I found in practice with the 2940W on an ASUS P55TP4XE is that it _will_
let you install the software, but the latest Novell patches and Adaptec
firmware (1.16)/drivers (ASPI 1.20, 7870 1.08) have at least as much to
do with it.  But switch off the extended translation, after first
doing it the "wrong" way, and you'll certainly get "missing operating
system".

Needless to say, I've redone my installation from scratch.  By the way,
is _anyone_ using tagged queuing with this card (2940W)?  What I've seen
to date on the list seems to indicate "not".  The .txt file is very
confusing, to wit:

(begin Adaptec prose)

Refer to your disk-drive's documentation to determine if tagged-queuing is
supported, and the maximum number of outstanding commands supported.
Default values are 8 and 2, respectively.  Examples of changing this
feature are below:

:load aic7870 max_tags=2 max_nontags=1
	   or
:load aic7870 tag_disable=ffff max_nontags=1

The first example is set for tag-queuing drives and the second case is
for non-tag-queuing drives. The max_tags parameter can be set as 2, 4, 6,
8, or 10.  The max_non_tags parameter can be set as 1 or 2.  Larger values
give the drives more opportunity for optimization, but take up more
memory in the server.  In some instances, drives may not support the
driver's maximum count, or may suffer starvation problems with large
counts.


The following table shows default values for driver command line options.
It was inadvertently left out of the NetWare section of your manual.
Please refer to the following table for the default values.

   OPTION               DEFAULT VALUE            RANGE
------------------------------------------------------------------------
   slot                 n/a                      1-15
   verbose              n                        y,n
   removable            on                       on,off
   fixed_disk           on                       on,off
   dev_enable           ffh                      00-ffh (bitmask)
   lun_enable           01h                      00-ffh (bitmask)
						  (default if lun 0 only)
   tag_disable          00h                      00-ffh (bitmask)
   io_combine           16 (decimal)             00-16 decimal
						  ** different than
						     manual **
   max_sectors          64 (decimal)             00-ffh
>  max_tags             8                        00-ffh
>  max_nontags          2                        00-ffh
   read_after_write     1                        0,1 (1=write and verify,
						      0=write only)
						  ** different than
						     manual **
   instrumentation      0                        0,1 (1=turn on
						     performance
						     instrumentation)
						  ** new feature **

(end prose)

For wide drives the bitmasks expand to "ffffh".

So what's with the "00-ffh"?  This looks suspiciously like the bitmask
values for "dev_enable", "lun_enable", and "tag_disable".  Fujitsu tech
support says max for my drive (M2915Q-512, 2.1GB) is 128.  Should I
believe it?  For now, I'm running tag_disable, max_notags=1 (may test 2)
before committing this baby to production.

Those of you so inclined to reply direct (or otherwise) on this subject,
I'll be more than happy to summarize to the list.

------------------------------

Date: Wed, 20 Dec 1995 00:25:00 MET
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: HELP!! abend:General Protection Processor Exception

>I'm running a novell 3.12 10 user server.  We have install an exabyte
>scsi tape drive (4gig) and and we are running a scsi 1 gig hard disk.  The
>server has 20 Meg of ram.  While everyone was on, the server crashed,
>everything was rebooted and now no one can get on.  The server seems to
>boot ok however everytime I try to down the server I get the following
>error Abend:General Protection Processor Exception Code FFFF0000.  Any
>ideas as to what could be causing my problem.  I've swapped out the
>ethernet card and that didnt do anything.  As I've said the server seems
>to come up fine.

The configuration you describe is allmost the same as mine.
I'm not sure about the type and brand of the devices but that shouldn't
make a big difference.

Anyway. Take the manuals that came with the hardware and reread them.
Ask yourself. Did I load the rights drivers in the right place in the
right order. Did I terminated my SCSI-bus as I should do?
Do all SCSI-devices have a unique SCSI-ID? Do the drivers know that?
Did I deactivate the floppy-connector on the SCSI-controller (some have
one). Is the SCSI-ID of the SCSI-controller the right one?
Are there any fancy gadgets on the SCSI-bus that I can turn off?
Do I need to tell anything to the CMOS on the server?

Most books about SCSI controllers have a trouble-shooting section.
I suggest you read that again and also the installation section.

Does it work if you disconnect the dat-drive?

------------------------------

Date: Tue, 19 Dec 1995 15:43:31 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Netware 3.12 duplexing drives

>I thought I would take advantage of this sharing season and solicit
>some help from this list.
>
>Here is the problem:  I am trying to setup duplexing on my Netware
>v3.12 machine.  After a period of time ranging from a couple of hours
>to a couple of days, the drives on the duplexed controller are
>deactivated by Netware.  I have performed the surface scan test on the
>drives in question and no errors were detected.  Therefore, as far as
>I can tell there is no problem with the drives specifically.  I have
>tried different combination for supplying TERM POWER; but that had no
>affect.  If anyone has any experience with this situation I would
>appreciate any insight.
>
>Thanks in advance for your time and help.
>
>Hardware particulars:
>
>system board is a Pentium 90mhz EISA;
>controllers are Adaptec 2742T;
>Hard drives are 2 Seagate ST42100 (2.0GB) HDs, 2 Seagate ST15150N
>(Barcuda 4.0GB) HDs;
>
>The drives are mounted in an external case with the termination of the
>SCSI bus at the Adaptec card and at the end of the external SCSI
>cable.
>
>In the EISA config I have setup the controller cards to disable BIOS
>and to disable extended translation for drives large that 1.0GB.
>
>I am loading the Adaptec ASPI driver for Netware AIC7770.dsk.
-------------
	Is the cache of each drive turned off? If not please do so with a
utility available from ftp.seagate.com.
	Are the SCSI cables the nice fat (and expensive) kind? If not please
replace with the higher quality expensive kind. Keep them short.
	Are rev numbers on the drive's firmware high? If not contact Seagate.
	Are those Barracuda's well cooled? If not crash and burn.
	Is EISA configuration properly set of the amount of memory in the
machine? If not lose one turn, do not pass GO, etc.
	Using the latest aic7770.dsk and aspitran from Adaptec? If not visit
ftp.adaptec.com.

	Why do you have the Bios turned off? Seems peculiar to me and rather
difficult to boot the machine. I run my Adaptec 2742AT's with the Bios
enabled and translation disabled. (One Bios will handle multiple boards,
but one 2742AT will handle 14 drives.)
	Joe D.

------------------------------

Date: Sun, 24 Dec 1995 16:59:28 GMT
From: Rex Kung <sysnac@SINGNET.COM.SG>
Subject: file "312it1.exe"

Encountered "spurious h/w int 15 detected" on HP Netserver LC,
using irq 10 on 3com PCI NIC, int 15 is from onboard HP netserver,
shifted to int 14 but error still persists...the server just hangs.
So I am looking for file "312it1.exe" mentioned in paragraph 7 below...

*** The following is from the HP Netserver troubleshooting guide ***

NETWARE SCSI DRIVE DEACTIVATION TROUBLESHOOTING TIPS

ISSUE:  Drive deactivation in the NetWare environment
	is caused by the inability of the disk driver
	to communicate with the drive.  When the driver
	cannot communicate with the drive, it will
	retry a few times.  If the driver still cannot
	establish a communication link with the drive,
	the driver will tell the operating system (OS)
	that the drive is not responding, and the OS
	then deactivates the drive to prevent data
	corruption.

SOLUTION: The following lists some measures to try if you
	  encounter drive deactivation:

1  Check the termination of the SCSI bus.  The SCSI bus
   must be terminated on both ends (internal and
   external), and the correct types of terminators must be
   used.  The device side of the cable must be terminated
   using HP part number 0960-0888 for all HP NetServer
   Series.

2  Check the SCSI cable (for example, try a different
   one), and replace it if necessary.  Reseat the SCSI
   adapter and all connectors.

3  Ensure that SCSI IDs are set properly.  The SCSI
   adapter and all SCSI devices must have unique SCSI IDs.
   Usually, the adapter will have a SCSI ID of 7, and the
   attached devices should start with SCSI ID at 0 and
   work up to 6.  Even without an ID conflict, Novell saw
   drive deactivation problems using a CD-ROM drive or a
   tape drive at SCSI ID 0, 1, or 2.  Novell recommends
   that CD-ROM drives and tape drives use SCSI ID 3 or 4.

4  Always use the latest Novell-certified drivers, and
   make sure that the drivers you use are compatible with
   the firmware revisions of your SCSI adapters.

5  Look for conflicts with other bus mastering cards.  If
   the system has other bus mastering cards that hold the
   bus for a long time, the disk driver may be prevented
   from communicating with the drive, which may cause
   drive deactivation.  Although this is rarely the case,
   it is still worthwhile to try different bus mastering
   cards or different drivers for those cards.

6  Check the SCSI adapter and drive (for example, by
   trying different ones). Although replacing the SCSI
   adapter or the drive with the same model may solve the
   problem, always try all other possible solutions first
   before replacing hardware that can be expensive for HP.

7  Use available NetWare patches.  Novell has a patch that
   may solve some of the drive deactivation problems in
   NetWare 4.01 and NetWare 3.12.  The patch is on
   CompuServe (TM), and its name is MMACCFIX.NLM.  The
   patch is included in 401IT1.EXE for NetWare 4.01 and
   312IT1.EXE for NetWare 3.12.

------------------------------

Date: Thu, 28 Dec 1995 15:57:22 -0800
From: "Robert S. Sfeir" <robert@VESTNET.COM>
Subject: Re(2): ADAPTEC 2842

I use 2 of them with 2 IBM fast wide drives!  This combo just screams.
Make sure you get the latest drivers!  I have had some intermittent
problems before upgrading, now they're just fine!  I use Netware 4.1.

------------------------------

Date: Thu, 28 Dec 1995 23:05:57 -0500
From: "Philip R. Reznek" <preznek@SUNBELT.NET>
Subject: Re: Server Yes, Dos No.

>I have installed a 2GB SCSI drive on one of the servers. Dos sees only
>1GB, however, Netware sees the whole 2GB. The Controller is an
>Adaptec 1740A.

You named the answer: 'Server Yes, DOS No'.

Don't touch a thing.  DOS versions can't see more than 1GB on a drive
without translation being set on in the controller.  Netware doesn't
like translation.  It's a no-no-no.  (The third 'no' is for
emphasis.)

If the server is booting from the drive, make the DOS partition the
first on the drive.  DOS will be able to see enough for the 10MB or
so that's usually needed for NW material.

------------------------------

Date: Tue, 16 Jan 1996 15:50:59 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Drive deactivation

>I've got the error message "Drive deactivation due to device failure"
>for the second time now.  Its a Seagate ST31230 connected to an
>ADAPTEC AHA2842A Busmaster SCSI controller.  Running the driver
>AIC7770.DSK
>	Adaptec 7770 Family Driver for NetWare v3.1x/d1.13
>	Version 1.13    September 5, 1995
>	Copyright 1992-1995 Adaptec, Inc.  All rights reserved.
>How do I find out what the real culprit is, drive dying or what?

Thomas, some things to check:
 - Older/incompatible firmware on the drive (see http://www.Seagate.COM)
 - Enabled on-board (on the drive) write-back cache, disable the
   write cache with settings of the Adaptec driver.
 - Overheated drive, check cooling & airco.
 - Bad cabling, check SCSI cables.

------------------------------

Date: Tue, 16 Jan 1996 07:44:00 PST
From: "Steve Bailey,NWSysAnl,METHEUS" <steveb@METHEUS.COM>
Subject: Re: Drive deactivation

>>I've got the error message "Drive deactivation due to device failure"
>>for the second time now.  Its a Seagate ST31230 connected to an
>>ADAPTEC AHA2842A Busmaster SCSI controller.  Running the driver
>>AIC7770.DSK
>>	Adaptec 7770 Family Driver for NetWare v3.1x/d1.13
>>	Version 1.13    September 5, 1995
>>	Copyright 1992-1995 Adaptec, Inc.  All rights reserved.
>>How do I find out what the real culprit is, drive dying or what?
>
>This is often caused by a badly set up scsi bus. I'd check again
>that only the last device on the bus is terminated.
>
>Been there, seen it, done it, read the book, saw the film, and ate
>the pie :(
>
>Roy.

I agree with Roy, every time I have seen this error it was associated with
a improperly terminated SCSI bus.  Interestingly enough, using the adaptec
2940 PCI card required me to enable SCSI termination, even though I had an
external device, which is being read fine.   When I disabled this option in
SCSI Select, it would cause the above error and dismount all my drives.

------------------------------

Date: Tue, 16 Jan 1996 15:14:00 -0500
From: Alex Lemmon <alemmon@MCIS.MESSIAH.EDU>
Subject: Re: Drive Deactivation

In response to the following inquiry -

>I've got the error message "Drive deactivation due to device failure"
>for the second time now.  Its a Seagate ST31230 connected to an
>ADAPTEC AHA2842A Busmaster SCSI controller.  Running the driver
>AIC7770.DSK
>
>	Adaptec 7770 Family Driver for NetWare v3.1x/d1.13
>	Version 1.13    September 5, 1995
>	Copyright 1992-1995 Adaptec, Inc.  All rights reserved.
>>How do I find out what the real culprit is, drive dying or what?

I encountered a similar problem a while back and tried the usual -

 - check for proper termination
 - verify SCSI device numbers
 - obtain "latest and greatest" drivers
 - verify proper power to drive
 - etc ...

All to no avail.

Then, through a series of trial and error experiments (and hair loss),
I found the problem to be the SCSI Transfer Rate.  Most (all?) Adaptec
cards come with the default SCSI XFER Rate at 10MB/sec.  As soon as I
backed that down to 5MB/sec. - the problem went away.  I then heard from
others that Adaptec cards were "quirky" that way.

------------------------------

Date: Tue, 16 Jan 1996 13:39:37 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Drive Deactivation

<Alex Lemmon's message above>
------------
	Methinks you have the wrong end of the cable. It's typically the
SCSI peripheral that's quirky (CD-ROM players being notorious this way),
and next in line is less than acceptable SCSI cabling. SCSI protocol
quality is often neglected in the rush to produce drives at lower and
lower cost. Many managers are unaware that cheap cables do not compute
at high speeds.
	Add to this VLB's inability to tolerate two or more bus masters
and it's quite a cocktail.
	Generally we recommend not even dreaming of using a VLB machine as
a NW file server; donate it to a deserving secretary. Motherboards are
cheap these days so replacing it with one suitable for stress is advised.
Even a plain ISA bus board with an ISA bus master SCSI controller (say the
venerable Adaptec 1542) will be more stable and about the same performance.
	I put all this into the pot of "common PC knowledge needed by every
experienced NW systems manager."
	Joe D.

------------------------------

Date: Tue, 16 Jan 1996 13:03:32 -0800
From: Mike Matthews <mmatt@HALCYON.COM>
Subject: Re: NOVELL Digest - 16 Jan 1996 - Special issue

>I've got the error message "Drive deactivation due to device failure"
>for the second time now.  Its a Seagate ST31230 connected to an
>ADAPTEC AHA2842A Busmaster SCSI controller.  Running the driver
>AIC7770.DSK
>	Adaptec 7770 Family Driver for NetWare v3.1x/d1.13
>	Version 1.13    September 5, 1995
>	Copyright 1992-1995 Adaptec, Inc.  All rights reserved.
>How do I find out what the real culprit is, drive dying or what?

I thought the 2842 was a PCI card.  Don't you use the AIC7870 driver
with it?

Anyway...

I had a similar problem with Adaptec's 2742AT.  This card was working fine
on a 486, but when I upgraded to a Pentium with an EISA bus, I got the
drive deactivation message.

I also had this problem when I set up another Pentium server with a PCI bus
using a 2840 and the AIC7870 driver.

I contacte Adaptec's technical support bulletin board and the advice I got,
which worked, was to load the disk driver with the following parameter in
the startup.ncf file:

load AIC7870 slot=XX tag_disable=ff

According to the controller card manual, this disables tagged queueing. It
worked for me.

------------------------------

Date: 26 Jan 96 10:54:23 EST
From: <Fernando_Vinan-Cano@pfm-tun-wells.ccmail.compuserve.com>
To: <netw4-l@bgu.edu>
Subject: Re: Stuff on SCSI channels

We've had problems with SCSI over the past year.

Our setup was initially two SCSI controllers : one an Adaptec 1740 with two
hard disks but separate volumes (SYS, DEV), the other an Adaptect 2740T (the
dual channel version) with another hard disk (mirrored SYS) on the primary
channel, and a CD-ROM and HP tape drive on the secondary channel.

We had no end of problems - backup's aborting or abending the server, random
disk deactivations (on rare occasions). Then when I added a second tape
drive off the back of the first nothing on that channel worked very well.

I bought the dual channel expressly for the purpose of splitting the slower
devices off, but obviously this has little to offer either.

Luckily a 1542CF became spare and now we have three SCSI cards with the CD
and two tape drives all working merrily away with no problems on their own
controller.

What's going on ???????

Fernando Vinan-Cano

------------------------------

Date: Thu, 15 Feb 1996 19:00:00 -0000
From: Chris Tilbury <Chris.Tilbury@warwick.ac.uk>
Subject: Re: Drive Deactivation

<In response to Joe's reply to Alex's comments on Adaptec controllers>

Well, I thought I'd chip in here with my experience - not with
spinning disk this time, but with DAT's. As I write this I'm
finally hopeful that I've cracked a problem with a 2472AT, with
an Archive Python (internal), HP C1533A (external), and a NEC 6xi
CD-ROM (internal, but irrelevant in this case as no drivers are
loaded for it and it might as well not be there) all on a
Dell PowerEdge Server.

Problem:

Archive Python (+ CD) originally installed on the servers
onboard PCI (ncr53c810 based) controller. No spinning disk (all
these live happily and safely on a separate RAID array controller)
chugging along happily with Storage Manager 4.0b2. Departmental
Computer Policy dictates that separate backups be taken to the
standard Tower of Hanoi routine (following an unpleasant experience
with the server being stolen).

Solution:

Purchase Adaptec 2472AT, HP C1533A. Place current internal
devices on channel "B" (internal only), HP C1533A on channel "A".
Termination properly configured (both channels, on card).

Agh! HP C1533A hangs the "A" channel; reboot of server and backup
to Python on "B" works. Perform "long device test" (650MB of test
pattern write/read/verify) - bus hangs after 80-100MB of pattern
is written. Test HP C1533A on workstation (with 2842 VLB) with
"Backup Basics" - back's up all 500MB fine.

Swap Python (+ CD) to channel "A", wait one night (next automatic
backup). Agh2! Python has hung the "A" channel. First idea -
is channel "A" defective (Adaptec? Not likely, though it could
be a very rare duff card, there's always one somewhere).

Read manual for 2742AT (well, honestly, I know I should of to start
with, but ...) - decide to change Xfer rates on the devices (onboard
PCI SCSI has no apparent configurable options as the Adaptec),
and discover that Dell have neglected to send a manual for the
Python, but tech support confirms that it's a maximum of 5.0MB/s
and C1533A manual reports a maximum of 7.5MB/s (CD is 5.0MB/s).

Change configuration of each device on the the SCSI card. (HP C1533A to
6.67 as this is the nearest to 7.5 MB/s available, Python + CD to 5.0mb/s).
Perform "long device test" on C1533A. All 650MB of data written
successfully; All 650MB of data read & verified successfully.

Conclusions:

Xfer rate configuration on the Adaptec's can matter - I didn't change
anything on the 2842, but if the workstation in question was managing
to get enough data across the SCSI bus to approach the maximum rates
I'd be amazed, whereas with the 2742AT in the server, I wouldn't be
(Hangs appear to have occurred whilst backing up very large (>15MB)
AutoCAD drawings).

Termination probably also an issue (knowing so shamefully little about
SCSI makes me cautious here) - the Python probably worked on channel
"B" because all termination was active - on channel "A", with termination
being a big chunky centronics block on the HP C1533A, I suspect that it's
passive and less capable (needless to say, I intend to order an active
terminator first thing in the morning)

------------------------------

Date: Sat, 2 Mar 1996 23:25:08 +1000
From: Richard Phillips <Richard_Phillips@MCINTOSH.COM.AU>
Subject: Re: SCSI setup

>I am planning on adding a SCSI hard disk to my Novell 4.10 network.
>Currently, I have four IDE drives and one scsi CD-ROM.  Any suggestions
>and help will be greatly appreciated.

* Get a decent card. Adapatec tend to be the most popular.

* Get a decent drive. There are many out there including the likes of
Quantum and Seagate barracudas (with the VERY important proviso that
barracudas MUST be in a well cooled box otherwise you will almost
certainly end up with drive failures).

* Do NOT use the same scsi controller for the hard drive(s) as you are
using for the CDROM or any tape drive.

* Do NOT use a VLB scsi controller for a server unless you like to
gamble. PCI are getting better but (if you decide to get a PCI card)
you may want to try to get it on trial just in case your motherboard
doesn't like it.

* Make sure you have enough memory to support the new volume

* Do not allow users to store important info on the new drive for at
least a month - the first four weeks are the danger period for drive
failure.

* Backup everything three times and make sure you can restore from the
backups BEFORE installing a new drive or in fact ANY new hardware in a
server.

* Unless you are not going to store important data on the new drive,
I'd try to get TWO drives and mirror them.

* If you are running out of space in your server, get an external box
BUT (again) get a decent one AND assuming you have a UPS remember to
plug the external box into that as well.

* Check the power rating of your server power supply - it is possible
that you may be pushing things with adding an extra drive, in which
case you will have to increase the power supply or get that external
box.

* If you use an external box, get a decent scsi cable and an active
(not passive) external terminator.

* General (very) rule - Buy the most expensive things you can

* Be very VERY paranoid - check everything and trust no-one.

------------------------------

Date: Fri, 8 Mar 1996 09:34:33 +0000
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: Hard Drive Diagnostics

>I am currently experiencing problems with my file server that I suspect
>are related to the hard drive. Does anyone know of any utilities which
>would enable me to determine if this is, indeed, the source of my problems.
>The problems include lockups and abends. The most recent abend message
>was "AddFile called with directory entry with invalid first disk block'.
>These problems have occurred off and on since October when the air
>conditioning in my server room went down and the server shut itself down.
>I have a 486DX/2 with 64 Mb RAM, Adaptec 2940 PCI adapter, and
>2 Micropolis 3.5 Gb SCSI hard drives. I am running NetWare 3.12 with all
>the latest nlms. Any ideas anyone?

There were problems with Micropolis drives and Adaptec controllers
under NetWare.  Micropolis has released updated firmware which may
solve your problem.  Try ftp.microp.com or PCVEND on Compu$erve.

------------------------------

Date: Fri, 26 Apr 1996 12:09:30 -0400
From: Larry Hansford <hansford@ERINET.COM>
Subject: Re: Connor Hard Drives

>I was having problems with 2 brand new Conner 2.14gb drives, the problem
>stemmed from a long INTERNAL SCSI Cable provided by the manufacturer.  It
>was a 7 connector cable, measuring in at about 5 feet, I cut two feet off of
>it and everything in now working just fine.  I've heard of a maximum of 6ft
>for SCSI but I belive that is for external cabling where you have some
>shielding.  Does anybody know the maximum you should run an internal SCSI
>ribbon cable?

As I recall, SCSI cables require 1 foot between devices, and a 5 foot cable
normally suppports 5 devices.  A 7 foot supports 7 devices.  At any rate,
the one corner you do not want to cut expenses is on SCSI cables.  Buy the
best, install it, and forget about it.  A cheap SCSI cable is just that.
There is no end to the grief that a poor quality SCSI cable can cause.

------------------------------

Date: Thu, 2 May 1996 13:49:13 -0700
From: John P. Kerti <johnk@KWANTLEN.BC.CA>
Subject: Re: Turning off Cache on Seagate Drives

>Could someone please tell where to find this program. I have looked
>at the SEAGATE FTP site and can not find any mention of a program to
>turn off the cache on there drives. I also can not find the ASPI-WCE.ZIP
>file which was mentioned earlier.

ftp.seagate.com/techuppt/seagate_utils/aspi-wce.zip

It took me a while to find it since its not off /pub and there is no
mention of it in the 00Index file in that directory.  To use it, just
unzip it and run aspi-wce.exe and it will prompt for a SCSI ID (0..6).
It will then tell you if Write cache enable is ON or OFF and it will ask
if you want to change it.

I've done these on 4 Seagate Hawks now but I wonder, I've browsed
Novell's site looking for a reference to problems with Hardware Write
Cache and have found nothing.  Is this a problem that is specific to
Seagate Hawks?  Or is it just that other drives have jumpers for doing
the same thing?

On another note, I ran a demo version of a program called Nettune Pro from
BMG and had it make a list of recommendations for tuning our server.  It
suggested that I turn "Read after Write verify" OFF and went on to
explain that this would speed things up a lot and only had to be ON on
old systems.  From the past discussions on this list, it seems that this
is not something you would want diagnostic software to suggest...

------------------------------

Date: Thu, 23 May 1996 13:27:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Adaptec 2740 and Drive deactivation

>I had a problem similiar to this happen twice, bu with 1542's.  I have a
>1542 hooked up to an internal 2gig disk and an external Exabyte 8200.
>
>Both times, everything was fine until the backups ran.  Upon examining
>Acrserve's logs after recovering the server, I found that the tape drive
>stopped responding, at which point Arcserve (or would it be the
>controller?) sent as SCSI bus reset.  I'm assuming it did this to try
>fixing its link to the tape drive.  This reset caused the disk to
>deactivate.  I couldn't get the tape out without powering off
>the tape drive.
>
>In the first instance, replacing the tape drive fixed it.  In the second
>instance, replacing the controller fixed it.
>
>John P. Kerti
--------
	Believable.
	Arcserve & similar high end tape backup programs are overachievers.
They POLL the living daylights out of the tape drive SCSI connection, and
the server's cpu utilization reflects this behavior. NetWare is not a
preemptive operating system; it is a cooperative (voluntary) release kind.
Thus when an NLM wants to it can hog the machine, and tape programs do so
in spades. Things break under that kind of stress.
	I use Arcada's BackupExec. It too polls nearly as fast as it can
go. In release 5 I turned off fast file finding (or similar name); in BE
release 7 it's off by default. This helps a lot.
	The Adaptec 2742AT is a fine board. I use a bunch and they give
no trouble. But not all SCSI devices are created equal. Weak sisters need
help by turning down the speed on their SCSI bus, by turning off frills
in disk drives (NO CACHING), and so on. In the end some devices are designed
so poorly that nothing much helps (see many CD-ROM players as living
examples, plenty of disk drives qualify too).
	Please attend to the buses on the PC. Tell all controllers to
release the EISA bus early; don't let them sit on it for a long time after
their expiry notice has arrived. Dig into the Bios and use conservative
settings on memory, cache, etc. There is no way we can tell what's wrong
there via Email, so use shrewd estimates of behavior. Ensure that the EISA
config program has been run against the motherboard too, such that all
memory is denoted there and there is NO Register Memory command at the
NetWare level.
	Check your SCSI cabling, and if necessary use active SCSI
terminators on external lines. Recall, cheap external SCSI cables are
skinny and totally worthless; good cables are fat as your thumb, expensive,
and worth every penny. If in doubt about electricals please call in a local
guru.
	Joe D.

------------------------------

Date: Fri, 4 Oct 1996 14:31:09 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: SCSI Voodoo

>I am adding an external drive to my Novell 3.12 server
>and this I know is unrelated to the operating system, but
>whenever I power up the system with the external drive
>connected it can't see SCSI ID #0.  I checked termination
>and verified the proper settings on my Adaptec Controller
>but still whenever the external is powered on, I can't see
>SCSI ID#0, even though the new drive is set to be SCSI ID
>#6.  The configuration is a Gateway PC (486) with
>two internal drives, Adaptec 1542 Controller and now my
>attempt to add an external 2.3GB drive.  Any ideas?

	Yup: You're in SCSI Voodoo-Land! :)

	This could be caused by one of a few problems... And I have seen
these (and even done a few, too!):

	1) Check your termination on the card and on each device on the
SCSI chain: You want only 2 terminators - One on each end. If you are using
both internal AND external devices then disable the terminator on the SCSI
card.

	2) Beware active termination. It's not the panacea that everyone
makes it out to be. What can happen with two active terminators on a SCSI
bus is that each will try to hold the lines to 2.85 volts... And small
voltage inconsistencies will cause high frequency oscillations between the
terminators as the "fight" each other.

	3) Check the "TE" (Termination Enable) jumper settings on each
drive, and make sure they are DISABLED where appropriate.

	4) Beware drive pinouts! It's really easy to install a thumbwheel
switch connector backwards, too. Go to the Web site for each drive mfr. and
*verify* the ID selector pinouts. Also beware that many drives have *two*
sets of ID selector pins.

	5) After performing the above, connect one device at a time and
boot the machine, watching the BIOS scan to verify ID's.

	6) Add one device at a time to find out which device is "toppling
over" the SCSI chain.

------------------------------

Date: Sat, 12 Oct 1996 09:18:11 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: Re: Data Corruption on NetWare 3.12 Server

>One of our departments is experiencing data corruption on one of our
>Netware 3.12 servers.  I ran a virus check, however, none was found.
>If we check the file size and date, they look fine.  The problem is
>with the internal structure of the file, which we found when we run a
>binary comparison of the files.

	[snip]

>Unfortunately, all files that are currently listed as having binary
>mis-matches remain corrupt when copied to another location.
>
>I did a complete restore of the volume about three months ago using
>Palindrome after a volume disappeared in an attempt to remirror a
>different volume.  I've also experienced quite a few hard crashes on
>the server for the past month.  Does anyone have an idea  what caused
>this or how to go about fixing this?

	SCSI Voodoo is my call. The volume disapperaing is the tip-off.
Check your hard drive cables and termination settings. Reflections caused
by impedance mismatches will cause drive data corruption every time: The OS
THINKS it has written to a given block, when in fact it hasn't. Seen this
one happen too many times (especially on artist's Macs with scanners &
SyQuest drives attached).

------------------------------

Date: Wed, 16 Oct 1996 14:17:54 GMT+800
From: YAM TAN <YTAN@WASP.CS.COWAN.EDU.AU>
Subject: New disk drive

> Cannot see SCSI hard disk from Netware 3.12

I had a similiar problem with this, ie DOS would see the drive and
when Netware is started, the drive is not shown.

I am using a Adaptec AHA1740 scsi card to support a internal and a
external drive.

I inherited the server and was to install a new external drive.

The thing that was stopping Netware from see the drive is an extra
parameter in the loading of the disk driver, ie

load aha1740 slot=1 dev_enable=41

As soon as I deleted the dev_enable=41 form the load line, Netware
can find the new external drive and it had been working for 4 months
now.

------------------------------

Date: Thu, 24 Oct 1996 10:23:42 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Annoying SCSI/Netware Problem

>I love SCSI to pieces, but sometimes it makes me so mad I could gnaw my own
>arm off at the elbow.
>
>Hokay.  Just got handed a server by another department that I need to sort
>out.  It needs a lot of sorting.  As configured, it's a Dell Omniplex 590 with
>64 megs, an onboard SCSI adapter (NCR is what shows in the BIOS) connected to
>an internal DEC SCSI hard drive, set to SCSI ID 6.  It's a 2 gig drive and it
>contains the SYS partition.
>
>Next up we have an Adaptec 2940 SCSI card connected to three external Seagate
>Barracuda ST-15150N (4 gig) hard drives, set to SCSI IDs 2, 3 and 4.  Together
>they comprise VOL1 (I know, I know, it's on my list of things to fix).
>
>VOL1 is, of course, the truly important volume.  I've backed it up once over
>the wire, which took darned near forever.  I *could* restore, except as all of
>this equipment is new to me, I'm not 100% faithful that the tape *would*.
>
>Anyway, the first thing I tried to do is toss a tape drive on this,
>specifically an Exabyte 8mm.  I tried setting it for SCSI IDs 0, 1, 5 and 6,
>but each time, when the server comes up, it aborts trying to mount VOL1 and
>says one of the drives (the one set as ID2) is deactivated due to drive
>failure.  Pull the tape drive out of the chain, everybody happy.
>
>I pulled the drives all out, double-checking for extra termination, but
>nothing.  I rearranged the SCSI chain, swapping out cables, but nothing.
>
>Finally, in an act of desparation, I renumbered the IDs of everything.  What
>was 4 became 0, what was 3 became 1.  2 stayed 2, and the tape drive became 3.
>
>VOILA!  It came right up.  No, I don't understand it at all.
>
>So today I try to add a second tape drive (set to 4) and guess what?  VOL1
>won't mount again.
>
>I've updated all the drivers.  No change.  I've rearranged IDs.  No change.
>I'm open to any suggestions before I panic.  Once the second tape drive is in
>and working, I can get multiple backups to different devices (and then move
>the hard drives to the internal SCSI controller so the tape drives are on a
>different channel), but having never done a test restore on this tape drive,
>I'm wary.
-----------
	Put boot drives on SCSI id 0, just like manuals say. Put other
drives from that ID upward. Tapes can go elsewhere.
	The NCR bios is highly variable, depending on which firmware is
in your machine, so try a flash update too. Remember, this is a simple
beast and the cpu has to run the controller code.
	When the bus breaks from an added device use common sense and lower
the SCSI negotiation speed and ensure all devices use parity (or all use no
parity), and if necessary turn off sync negotiation for the weak devices.
	You didn't mention cables, but the thin external cables are total
junk. Thick round external cables are the items to acquire, the more costly
the better. Ribbon cable is just fine, but separate the connectors by a foot
or so. Get terminator power under control so it is always present. Recheck
SCSI id versus jumper settings because some jumper blocks may read backward.
	Joe D.

------------------------------

Date: Thu, 24 Oct 1996 16:14:31 -0700
From: Donovan Bray <dbray@BASS.CUESTA.CC.CA.US>
Subject: Re: Annoying SCSI/Netware Problem

> The 2940 is a dual bus controller.
> You can have 14 devices on the card, 7 on each bus.

Actually this is incorrect: The 2940 is a SINGLE channel SCSI Controller.
Maybe you actually Mean the 3940?

AHA-3940 multichannel SCSI Host Adapter
AHA-3940W Wide multichannel SCSI Host Adapter
AHA-3940U PCI multichannel UltraSCSI Host Adapter
AHA-3940UW PCI multichannel UltraSCSI Host Adapter
AHA-2940UW PCI UltraSCSI Host Adapter

The 2940UW does support 15 devices, however they are ID's 0-6,8-15 and this
IS a single bus, you need to use Wide Devices to access the higher SCSI
ID's.

Note the AHA-2940 is different from the AHA-2940UW, the original 2940 only
supports
7 devices, up to Fast SCSI II.

10Mbytes/sec = Fast SCSI II
20Mbytes/sec = Fast Wide SCSI II
20Mbytes/sec = Ultra SCSI
40Mbytes/sec = Ultra Wide SCSI

Also note for the uninitiated, that WIDE devices use a 68 pin SCSI cable,
NOT a 50 pin. Also note that the 3940W and 3940UW only provide a 50 pin
INTERNAL connector, I recall their may be a SCSI tranciever available to
use the external 68 pin connector with Non-Wide Devices, best to contact
Adaptec if you have this difficulty.

---------

Date: Fri, 25 Oct 1996 18:44:13 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Annoying SCSI/Netware Problem

>>>The 2940 is a dual bus controller.
>>>You can have 14 devices on the card, 7 on each bus.
>>
>>Actually this is incorrect: The 2940 is a SINGLE channel SCSI
>>Controller. Maybe you actually Mean the 3940?
>
>You are correct. I was thinking of the 2740, which is a dual
>bus controller. Thanks for your comments.

2740T << TWIN channel card
2740W << WIDE card
2740  << Single channel card

------------------------------

Date: Thu, 24 Oct 1996 15:16:10 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: SCSI Voodoo

>I love SCSI to pieces, but sometimes it makes me so mad I could gnaw my own
>arm off at the elbow.
>
>Hokay.  Just got handed a server by another department that I need to sort
>out.  It needs a lot of sorting.  As configured, it's a Dell Omniplex 590 with
>64 megs, an onboard SCSI adapter (NCR is what shows in the BIOS) connected to
>an internal DEC SCSI hard drive, set to SCSI ID 6.  It's a 2 gig drive and it
>contains the SYS partition.
>
>Next up we have an Adaptec 2940 SCSI card connected to three external Seagate
>Barracuda ST-15150N (4 gig) hard drives, set to SCSI IDs 2, 3 and 4.  Together
>they comprise VOL1 (I know, I know, it's on my list of things to fix).
>
>VOL1 is, of course, the truly important volume.  I've backed it up once over
>the wire, which took darned near forever.  I *could* restore, except as all of
>this equipment is new to me, I'm not 100% faithful that the tape *would*.
>
>Anyway, the first thing I tried to do is toss a tape drive on this,
>specifically an Exabyte 8mm.  I tried setting it for SCSI IDs 0, 1, 5 and 6,
>but each time, when the server comes up, it aborts trying to mount VOL1 and
>says one of the drives (the one set as ID2) is deactivated due to drive
>failure.  Pull the tape drive out of the chain, everybody happy.
>
>I pulled the drives all out, double-checking for extra termination, but
>nothing.  I rearranged the SCSI chain, swapping out cables, but nothing.
>
>Finally, in an act of desparation, I renumbered the IDs of everything.  What
>was 4 became 0, what was 3 became 1.  2 stayed 2, and the tape drive became 3.
>
>VOILA!  It came right up.  No, I don't understand it at all.
>
>So today I try to add a second tape drive (set to 4) and guess what?  VOL1
>won't mount again.
>
>I've updated all the drivers.  No change.  I've rearranged IDs.  No change.
>I'm open to any suggestions before I panic.  Once the second tape drive is in
>and working, I can get multiple backups to different devices (and then move
>the hard drives to the internal SCSI controller so the tape drives are on a
>different channel), but having never done a test restore on this tape drive,
>I'm wary.

	Rule 1) Always set the SCSI ID of the boot device to 0.
	Rule 2) If possible, always try to have different SCSI ID's for
each device,  *regardless*  of the bus they are on. On the Mac, multiple
bus ID resolution is taken care of with SCSI Manager 4.3; and there is an
equivalent pee cee standard;
	3) On the Adaptec 2940, verify that the SCSI initiator is ID7... It
can be changed;
	4) Hit Control-A on boot to verify that every device is being seen
on the 2940... And do the same for the NCR chip;
	5) Lock the SCSI controllers into Synchronous mode... You'll lose
about 20% speed; but it MAY help;
	6) Put your slower devices farther out, physically, on the chain;
	7) Verify the ID on the ST15150N drives: They have  *TWO*  sets of
ID selector pins... One set on the side, the other on the end;

------------------------------

Date: Mon, 28 Oct 1996 09:56:49 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: SCSI information goldmine

	I've hit upon an excellent source for answering all your questions
about SCSI issues, troubleshooting, specifications, etc... So far, in all
my checking it's dead on target. The locations are:

<http://www.cis.ohio-state.edu/hypertext/faq/usenet/scsi-faq/part1/faq.html>

and:

<http://www.cis.ohio-state.edu/hypertext/faq/usenet/scsi-faq/part2/faq.html>

------------------------------

Date: Fri, 1 Nov 1996 13:18:17 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: <No subject given>

	Recently on this list there was a discussion of SCSI vs. IDE in a
server. Below, from:

<http://www.cis.ohio-state.edu/hypertext/faq/usenet/scsi-faq/part1/faq.html>

is some very good info worth quoting.


====
QUESTION: What are the pros and cons regarding SCSI vs IDE/ATA ?
ANSWER From: Gary Field (gfield@grcelect.ultranet.com)
====
Pros of IDE/ATA:
	Inexpensive due to high volume of production
	Supported directly by system BIOS in most cases
	Less overhead per command

Cons of IDE/ATA:
	Very limited device attachment (two drives including CDROMs)
	Only supports disk, CDROM (and limited support for tape)
	Single threaded (commands do not overlap even with a second drive)
	CPU is tied up transferring all data
	IDE/ATA and ATAPI evolved as one kludge on top of another
	  (so compatibility is not always good)
	Cannot handle scatter/gather operations well

Pros of SCSI:
	Flexible device attachment (up to 7 or 15 devices per SCSI bus)
	Support for almost any peripheral type (disk, tape, CDROM, scanner etc)
	All commands can overlap with commands on other devices
	Usually uses DMA to transfer data (which frees CPU for other tasks)
	Interface and protocol is carefully specified by ANSI
	Largest, highest performance devices are available in SCSI before IDE
	Most adapters can do scatter/gather DMA which is a necessity in
	virtual memory systems (Like Unix, NT) (Win 95 ?)

Cons of SCSI:
	Generally more expensive than IDE/ATA
	Slightly more complicated to install than IDE/ATA


====
Should I spend the extra money on SCSI or just get IDE?
ANSWER From: Gary Field (gfield@grcelect.ultranet.com)
====
For home users this is a difficult question to answer in general.
It totally depends on how you use your system, what operating system is
installed, and whether you will add more I/O devices in the future.
For server systems in a corporate environment the only sensible answer is
to go with SCSI peripherals.
IDE/EIDE is single threaded by nature. The current command must complete
before additional commands can start. With most IDE adapters the processor
must be involved in reading/writing the data from/to memory. Another drawback
is that only two drives can be attached. In a single drive single-tasking
system IDE will probably be slightly faster and is definitely less expensive.
When you start talking about multi-tasking operating systems (like Win95, WinNT,
Unix, OS/2 and Netware) SCSI is now a big advantage. As disk drives get bigger,
backup devices are becoming even more important. In my opinion floppy tapes
just aren't satisfactory. They're too slow, too unreliable, non-portable(media
exchange wise not physically), and have low storage capacities. SCSI tape
drives are more expensive, but have none of these problems.
SCSI devices share the bus bandwidth efficiently by allowing one device
to transfer data while another is seeking or rewinding its media.
Early SCSI implimentations had some compatibility problems but these days
SCSI is simpler to install than EIDE.
Each user needs to make this choice individually, but if you don't consider
all the issues, you can find yourself needing to re-vamp all your I/O to
add a device later on. Before you decide to go with IDE, ask yourself if
you will ever want to add a CDROM, CD-R, scanner, or tape drive or need more
than two hard disk drives.

Here's a discussion that shows some of the advantages of SCSI in more detail:
from: Greg Smith (GREGS@lss-chq.mhs.compuserve.com)

Under DOS (and DOS/win3.1), there is very little useful work the host
can do while waiting for a disk operation to complete.
So handing off some work from a 66 MHz 486 to, say, an 8 MHz
Z80 (on the controller) does result in a performance
loss. Under EVERY other OS worth discussing (Unix,
Netware, NT, OS/2, Win95 etc) the processor can go off
and do something else while the access is in progress,
so the work done by the other CPU can result in a
performance increase. In such systems, due to virtual
memory, a 64K byte 'contiguous' read requested by a
process may be spread to 16 separate physical pages.
A good SCSI controller, given a single request, can
perform this 'scatter/gather' operation autonomously.
ATA requires significant interrupt service overhead
from the host to handle this.

Another big issue: ATA does not allow more than one
I/O request to be outstanding on a single cable, even
to different drives. SCSI allows multiple I/O requests
to be outstanding, and they may be completed out of
order. For instance, process 'A' needs to read a block.
The request is sent to the drive, the disk head starts
to move, and process 'A' blocks waiting for it. Then,
process 'B' is allowed to run; it aslo reads a block from
the disk. Process B's block may be sitting in
a RAM cache on the SCSI controller, or on the drive
itself. Or the block may be closer to the head than
process A's block, or on a different drive on the
same cable. SCSI allows process B's request
to be completed ahead of process A's, which means that
process B can be running sooner, so that the most
expensive chip - the system CPU - tends to spend less
time twiddling its thumbs.  Under ATA, the process B
request cannot even be sent to the drive until the
process A request is complete.  These SCSI capabilities
are very valuable in a true multi-tasking environment,
especialy important in a busy file server, and useless
under DOS, which cannot take advantage of them.

I tend to hear from people, 'Well, I never use multitasking'
because they never actively run two programs at once - all
but one are 'just sitting there'. Consider what happens
though, when you minimize a window which uncovers parts of
four other application windows. Each of those applications
is sent a message telling it to update part of its window;
under win95, they will all run concurrently to perform the
update. If they need to access disk (usually because of
virtual memory) the smoothness of the update can depend a
lot on the disk system's ability to respond to multiple
independent read requests and finish them all as quickly
as possible; SCSI is better at this.

So, yes, ATA is faster under DOS; but SCSI provides
advantages which are inaccessible to DOS. They will
benefit Win95 however. The cost of intelligent, fast
SCSI controllers and drives should decrease as people
discover these advantages and start buying them.
I should add that many of SCSI's advantages are NOT
available with some of the simpler SCSI controllers
which were targeted only to the DOS market or part of
cheap CDROM add-on kits.

Furthermore, SCSI allows far greater flexibility of
interconnect. I concede that for the mass market,
which likes to buy pre-configured machines, this
is but a small advantage.

------------------------------

Date: Fri, 06 Dec 1996 10:48:29 -0700
From: Shawn <opeth@futureone.com>
To: netw4-l@bgu.edu, netw4-l@bgu.edu
Subject: Re: EIDE VS. SCSI

>>Can anyone tell me what performance/reliability penalties I may be facing
>>here?
>
>With current technology, the max. transfer rate for an EIDE drive is 16.67
>MB/sec (that Mode 4).  With SCSI, the max. transfer rate is 40 MB/sec
>(that Ultra Wide SCSI).  As I see it, you would have most likely used
>Fast-SCSI 2 drives which has a max transfer rate of 10 MB/sec.
>
>SCSI is a better for servers.  When the SCSI controller issues a command
>to a drive, the drive disconnects from the SCSI bus until it has the data
>requested.  This allows the controller to issue commands to other drives
>on the SCSI bus.  In addition, you can place seven devices on a SCSI bus
>verses two on an EIDE bus.

Other considerations:

1) EIDE still (to my knowledge) doesn't support overlapped, multitasking
I/O, whereas SCSI does (see Robert's comments above). That means that the OS
will have to wait until the request to the device has been completed before
it can issue another request. SCSI uses command tag queuing and can thus
issue 256(?) requests at a time. This can make a huge difference on
disk-intensive systems.

2) I think EIDE still doesn't support bus-mastering (SCSI does), but I'm not
sure of this. Bus-mastering (as you probably know) offloads work from the
CPU, thus reducing CPU utilization significantly.

3) Most non-SCSI devices (ie: EIDE) don't have sector-remapping capability,
which is an important part of a fault-tolerant system.

4) Novell doesn't approve of mirroring/duplexing EIDE drives in a NetWare
server. In fact, they go so far as to say it can't be done at all. However,
this is not true, as I've done it myself a bunch of times.

5) Most SCSI HBAs also have external connectors, allowing for daisy-chaining
of (if it's a separate channel) another 7 devices.

---------

Date: Sat, 7 Dec 96 00:36:11 -0000
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: EIDE VS. SCSI

<snip>
>5) Most SCSI HBAs also have external connectors, allowing for
>daisy-chaining of (if it's a separate channel) another 7 devices.

Good comments, Shawn. One correction, however - SCSI I and II support 7
drives/chain and external devices, the wide formats support 15
(theroretically), firewire supports 96 and Fiber channel supports 128.
The last two also have provisions for multiple hosts and hold out the
possibility of network attached drives, and are shipping technology. The
fun part incudes fiber channel switches - can you say ungodly throughput?

Also, don't forget that the BUS throughput is meaningless, as long as
it's higher than the max agregate throughput of the drives on that bus.
EIDE supports only 2 drives per channel, so that 16 MB transfer rate
isn't going to be taxed just yet.

------------------------------

Date: Tue, 28 Jan 1997 21:56:02 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Re: scsi card question

>I am getting ready to take randy's advice and add a third scsi card
>to my server to help eliminate a drive deacivation.
>
>I am going to have each drive on its' own scsi, and a 3rd scsi for
>the cdrom and tape drive.
>
>
>I am currently not using the cdrom drive so activity throughout the
>day is not significant, if any.  how important is the quality of the
>scsi card to be used with the tape backup?  I mean, the back up is
>done automatically at night when no one, I mean no one is using the
>machine.
>
>I had a price for @$300 for an adaptec scsi card eisa, novell
>certified, etc. and then a plan old scsi card @$70.  I realize this
>is for backups, but no one is one the machine.
>
>I already have an adaptec 2740fast wide card I will be using, this
>is just a what if question.

This is a question that gets kicked around a lot.  And there are at
least two correct answers.

For my file servers at home, whatever is cheapest that week gets
installed.  For production servers and customers, I *strongly*
suggest good name brand cards with Novell approval.  It saves me
sleep and the customers money.

What is the cost per hour of down time?  What is the cost for an hour
of a system engineers time?  What's the cost of an incident with
Novell?  The cost savings can be eaten pretty quickly.

Here's my suggestions:

1.  If money is an issue, move one hard drive that is sharing a
controller with the tape drive to the other controller.  That will
mean you will be mirrored rather than duplexed.  This will cause
about a 5 to 10% performance loss in high utilization environments.
It will allow you to determine if the card is the issue with no cash
outlay.  (Remember to make sure the two drives have different scsi
ID's.)  You may also discover that the performance is adequate.

2.  If you feel the need to stay duplexed, and the need to move the
CD-ROM's and tape drives to a different controller, then get the same
sort of controller you already have.  It will minimize installation
hassles - you can look at the other card and see how they are set up.

3.  If you can't quite manage to buy another Adaptec, here's my
alternate suggestions:

A.  The speed on the tape and cd-rom controller is not that much of
an issue - get an ISA bus Adaptec card.

B.  Look at DPT controllers - in ways I like them better than
Adaptec's.

C.  Look around for a card that uses the NCR chipset - they have been
fast and reliable for me, and a PCI card with that chip set can often
be found for around $60 to $80.  However, now we're getting into what
I'd do at home.  Look for Novell certification.

A final comment - Novell certification is very stringent, and there
is some argument about how relevant it is.  Let's say you are a
hardware manufacturer and put together a system with your own
motherboard, 64 megs of ram, your own scsi controller, two 4 gig hard
drives (mirrored), and a 3com ethernet card and certify it.  If you
change drives, the resulting system is not certified, even if the
drives you put in are separately certified.  Let's say you switch to
a SMC ethernet card - the system is no longer certified, even if the
SMC ethernet card is.  Let's say you add memory... the system is no
longer certified.  A change of bios versions?  A change of video
cards?  or video bios?  Or drive bios?  Any of these means that the
resulting system is not certified.  Still, I would rather add a
certified component than a non-certified one, but even the component
certification is limited - it is certified to work with the systems
it was certified with.  Some people feel that Novell's certification
is essentially useless for the customer.

------------------------------

Date: Wed, 29 Jan 1997 10:33:16 -0500
From: Doug Black <DBlack@SARCOM.COM>
Subject: Re: Micropolis RAID

>Management has requested installing a Micropolis RAID (Radion) on an
>HP Netserver LC.  Please let me know if there are any gochas.

Bill, I have used Micropolis RAID arrays, and they are... adequate.  Some
gotchas:

1. You can't have a DOS partition on the array -- hence you must boot
   from a separate HD or from floppy <ugh>.

2. I believe that all Micropolis RAID arrays require an Adaptec SCSI
   controller.  You *must* have BIOS on the HA disabled or the array won't
   initialize.

3. Micropolis sold its RAIDION product line to another company (I forget
   who).  You may want to think twice before installing an orphan product.

You didn't say whether this RAIDION uses the Gandiva hardware array
controller. If not, it implements RAID in software, with a corresponding
hit on server CPU utilization.

In short, if you're getting this array as a gift, it's worth tinkering with
to get working.  If this is a proposed purchase... DON'T DO IT!!!   A far
better RAID solution, IMHO, is DEC's Storageworks line.

---------

Date: Thu, 30 Jan 1997 09:18:00 +0100
From: Bjorn Sundqvist <bst@JPSL.JP.SE>
Subject: Re: Micropolis RAID on HP Netserver LC

We have used the Micropolis Radion RAID system, and I can't recommend it
at all. They replaced our system twice and it was still not working
properly. The disk would work for a month and then it halted. When bad
disks where replaced the drive would not update the information and all
files became useless. Micropolis offered to send a technician, he can be
at your place within 2 months.

After some discussion Micropolis offered us ordinary disks and now our
problems are long gone.

If I would give any recommendations after this I have to say - don't use
RAID systems. Use disk-duplexing which in my opinion are safer, cheaper
and much more flexible.

---------

Date: Thu, 30 Jan 1997 08:58:38 -0600
From: Rajnish Mishra <mishra@ALPHA.NLU.EDU>
Subject: Re : Micropolis RAID on HP Netserver LC

We have been using Micropolis RAIDION(now StreamLogic) for a year now.
It can have a DOS partition, you have tons of choices on how you wish to
configure it.  It also has EXCELLENT tech' support. It also comes with
hot-swap capability and can be configured for as many volumes as you want.

Also, do go in for Gandiva, coz it is simply the best.

------------------------------

Date: Tue, 4 Mar 1997 21:23:32 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Trouble with SCSI

>I have built a server using the following components:
>
>Two Western Digital Enterprise 2110MB WDE2170-0007 SCSI drives
>One Adaptec 2940 AU host adapter
>8 x 32MB SIMM
>Asus P/I-P65UP5 with a C-P6ND board, BIOS version 02.05
>One 200MHz PentiumPro
>One 3COM 3C900TP Etherlink XL board
>An ATI Videocharger 1MB VGA board
>
>Problem: if the computer is warm-booted or if the reset button is pressed
>the AHA2940 is unable to find the hard drives. The host adapter seems to be
>correctly initialized because the "Press CTRL-A" message is displayed.
>If on the other hand the power is circulated everything works fine.
>
>I made sure that one of the hard drives is LU 0, the other LU 1 and that LU
>1, which is the last device on the SCSI chain, is terminated. The AHA2940
>is LU 7.
---------
	Actually that's not LU but a SCSI ident/unit number. LU's are
different SCSI channels (buses) such as on the dual channel Adaptec boards.
But we get the idea.
	I would not be surprized to learn the WD disk drives cannot deal
with high speed SCSI comms. To find out turn down the max negotiated SCSI
bus transfer rates on those drives. Also enable parity on each, just in
case.
	Check the quality of those SCSI cables, and the termination too.
Cheap cables are death at high speeds, overly long cables are too. Active
termination is desirable at high speeds. Ensure that something does supply
power to the terminator wire on the SCSI bus.
	Be aware that ATI video boards often use memory addresses at the
15MB level. That can clobber your server unless a) you tell the BIOS to
leave a memory hole there or b) you use a better behaved video adapter.
The warm-boot-to-work symptom points at the video board.
	Joe D.

---------

Date: Wed, 5 Mar 1997 22:37:00 +0100
From: Peter Graus <peter@GRAUS.SE>
Subject: Re: Trouble with SCSI

Today I happened to read in the (excellent) German computer magazine c't
(March 1997, page 187ff) a review of hard drives, among them a Western
Digital Enterprise 2GB. They had excactly the same problem as I. They
"solved" it by disabling the drive's write cache.

The reviewer used different SCSI adapters and found that the drive did not
work reliably when connected to a Symbios Logic SYM8751SP or an Adaptec
2940UW. No problems were reported when an Adaptec 3940UW or a NCR 8251 was
used.

------------------------------

Date: Sat, 22 Mar 1997 16:59:56 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: SCSI

>>>I have two, 1.08gb drives mirrored on a 3.12 server.  The possible
>>>problem is that the Seagate shows a 12-bit FAT and the Fujitsu shows
>>>a 16-bit FAT when I check the settings of Partition info of the
>>>install.nlm.
>>>
>>>I already crashed the server once when I ran Vrepair with a 3.2GB
>>>Quantum spanned to the Seagate.  I know, I know, "don't span volumes
>>>across multiple disks!"  Some of us have to learn the hard way.
>>>Is part of the vrepair problem due to the different FAT sizes?
>>---------
>>	FAT's are a logical abstraction of the operating system, not a
>>property of the disk drive. DOS decides how to construct its tables based
>>on size of the DOS partition. Check your controller for mapping of heads
>>cylinders and sectors for DOS and ensure that such mapping is not done
>>for NetWare. Check termination and so on down the usual SCSI checklist.
>>	Joe D.

Joe is referrring to the ability of some SCSI controllers to present a
large SCSI disk to DOS as if it did have a large number of heads and
sectors so the number of tracks/cylinders falls below 1024. since we
aren't running DOS on our server, except for when it boots we don't
need this ability and SCSI controllers should be configured NOT to do
such a mapping. If you do have your controller configured to do the
mapping then mysterious abends and freezes often result. Alas if you
chnage the switch over you'll probbaly have to remake all of the volumes
on the disk.

SCSI devices present themselves to the SCSI controller as having a
contiguous series of blocks. SCSI disks will re-map bad sectors
internally and continue to present themsleves as bsing flawless UNTIL
they run out of these 'spare' blocks, at which point the number of
remapped blocks done by netWare will start to increase.
TIP: if you've a SCSI disk showing remapped blocks under netware this
is an indication that the drive is going to start failing sometime soon
and it's time to order a spare...

---------

Date: Sat, 22 Mar 1997 13:01:55 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: Re: SCSI: Sigh...

[Referrring to Richard's message above, Dan Schwartz theorized...]

	You are confusing Factory bad blocks with User bad blocks. Factory
bad blocks are those that are mapped out and stored on the disk in the
first track by the factory itself; and is generally not available to the
user or OS...including NetWare. This information is  **platform
independent:** Mac, Alpha, PC, etc... This information deposited by
the factory is read when the disk drive itself boots up (initializes) at
power-up or when a SCSI device reset is issued by the Initiator.

	In addition to the Factory bad block location, the drive parms are
kept on this first track.

	When a SCSI drive is "formatted" (actually a high-level formatting,
when the file system is installed), the drive is tested again for bad
blocks... But the Factory blocks are already passed over by the controller
on the drive itself and already "hidden" from the host, unlike IDE.

	Anyway, when a bad block is found during user formatting, it is
(supposed to be) mapped out in a different location from the Factory bad
blocks. These are called "Grown Defects;" and are typically managed at the
OS-specific and platform-specific] disk driver level -- but NOT the Factory
level. [This is actually quite important when switching a SCSI drive from,
say, MacOS to Alpha/NT and back to MacOS: The Grown defect list is lost
each time the driver is replaced; and the drive needs to be thoroughly
"scrubbed" for User bad blocks... But the Factory bad blocks remain safely
hidden away by the disk drive itself on it's power-up.

	What NetWare is doing (at least as I understand it) is constantly
checking for bad blocks in the background on it's own thread. Same for NT.
[By comparison, this is handled by Norton Disk Doctor as an exclusive
foreground process on the Mac (Floyd: or DOS PC).] When a bad User block
is found, it is mapped out and reported accordingly.

	I'll defer to your account of the process in NetWare, as it seems
reasonable that if NetWare reports it is finding bad (User) blocks that the
drive is rapidly approaching the failure point and should be replaced with
dispatch.

	[Actually, a much better indicator is the head flying height: If it
drops to less than half the initial (Factory) flying height, then the drive
will typically fail in 24 to 48 hours. See IBM's White Papers on Predictive
Failure Analysis for hard disk drives. And, PFA is implemented on their
7200 RPM UltraStar drives.

	Question for the list: Does NetWare's driver periodically poll this
information?]

	Disclaimer:  I don't service or support x86 machines. I strictly
service DEC Alpha's and PowerPC's (Macs & RS/6000's). The information
I'm providing above is pure, un-hacked SCSI operation; and
platform-independent... `cept for the x86 hacks.

---------

Date: Sat, 22 Mar 1997 11:11:35 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: SCSI: Sigh...

[To which Joe D. replied to Dan's post above...]

	No, wrong. The disk drive itself holds bad block information,
both at factory test time and later during normal operations. One can
look at both by using a SCSI drive examination tool such as SCSICNTL.
Drivers do not hold such information. There is no good reason drivers
would want to because the drive controller handles such things. Bad
block info is stored typically on the last (innermost) track, not on
the valuable track 0 (or nothing would boot).
	Joe D.

---------

Date: Sat, 22 Mar 1997 13:52:39 -0700
From: Shawn <opeth@FUTUREONE.COM>
Subject: Re: SCSI: Sigh...

>TIP: if you've a SCSI disk showing remapped blocks under netware this
>is an indication that the drive is going to start failing sometime soon
>and it's time to order a spare...

You should have said "this is an indication that the drive is _most
likely_ going to start failing...". It could also be a sign of a failing
host adapter or even (less obvious) something like memory.

---------

Date: Mon, 24 Mar 1997 00:33:16 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: SCSI: Sigh...

>You are confusing Factory bad blocks with User bad blocks. Factory
>bad blocks are those that are mapped out and stored on the disk in the

Dear Dan

Stick to things you know about. I won't comment about Power PC's if
you won't comment about things you obviously don't know about.

---------

Date: Mon, 24 Mar 1997 00:37:31 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: SCSI: Sigh...

>You should have said "this is an indication that the drive is _most likely_
>going to start failing...". It could also be a sign of a failing host
>adapter or even (less obvious) something like memory. Other than that, I

Okay, however I've not normally experience host-adapter failures in the
mode where it affects only the one disk drive on the chain.

Memory failures are more likely to abend the fileserver under unusual
circumstances, like high CPU load.

------------------------------

Date: Fri, 18 Apr 1997 03:25:48 GMT
From: James Jang <jjang@PERTECH.COM>
Subject: IntranetWare & HP T4000s SCSI Tape Drive

I am posting this message as a warning for network administrators / vendors
who are installing or looking at new tape drives.

We finally found out today that the HP T4000s SCSI Tape drive is
INCOMPATIBLE with IntranetWare.  HP doesn't know where the problem lies,
but understands there is a problem.  They have no idea when the problem
will be fixed.

If anybody has any info on this please e-mail me at jjang@pertech.com

---------

Date: Fri, 18 Apr 1997 09:07:09 -0600
From: James Hooper <HOOPER@WPOGATE.SLU.EDU>
Subject: HP T4000s

In the last mailing, someone had mentioned that a T4000s was
incompatible with Intranetware.  On a different note, we had a problem
with the T4000s in that it wouldn't read tapes made by an older T4000s.
A computer (with the internal tape drive) was stolen.  When we replaced
the machine with a new T4000s, it wouldn't even recognize the format of
the tape.

Aside from obvious conclusions that the first drive had been "doing its
own thing," HP recommended that I "downgrade" the firmware from 1.07
to 1.05.  I did this and it STILL did not recognize the tapes.

Even though I explained that the tapes contained valuable financial data,
HP refused to help further.  The "customer service" representative told
me that it was a "media issue" and that HP was not a media company,
and that I was ON MY OWN.

Boos and Hisses on HP.

------------------------------

Date: Fri, 9 May 1997 15:51:18 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Intel Venus MB and Adaptec 2940uw Controller

>I had an Intel Pentium Pro 200 venus motherboard with an adaptec 2940uw
>controller and used the controller for a user volume (sys was IDE).  it
>worked great.  I moved the controller to another Intel Pentium Pro 200 venus
>motherboard and when I install NW4.11, it dismounts the SYS when copying the
>netwareip software and I can't remount the sys volume.  I get alot of write
>errors on the FAT table from the system console.  I read here about the
>1540, but not the 2940uw.  I haved tried it in a middle PCI slot and an end
>one (no diff).  I have tried completely different hard drives, too.  Another
>weird problem is when installing NW4.11, It says that my DOS partition is
>only 3mb do I want to continue (even though it's actually 50mb).  I have
>downloaded the latest drivers from novell and adaptec for this and that
>doesn't work either.

	The standard SCSI suggestions apply: detune SCSI rates, ensure
termination really is proper and good, ensure cables really are good,
turn on parity, temporarily turn off sync negotiation as a test, don't
mix disk and CD-ROM (or other SCSI weak-sister) units on the same bus,
and so on. Once the real cause has been discovered one can restore many
settings.
	Also, look hard and long at the motherboard configuration and
Bios setup parameters. Be conservative. Watch those memory SIMMs because
flakey ones can wreck havoc.

<snip>

	Joe D.

------------------------------

Date: Sat, 10 May 1997 08:48:19 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: SCSI troubleshooting

>>	The standard SCSI suggestions apply: detune SCSI rates, ensure
>>termination really is proper and good, ensure cables really are good,
>>turn on parity, temporarily turn off sync negotiation as a test, don't
>>mix disk and CD-ROM (or other SCSI weak-sister) units on the same bus,
>>and so on. Once the real cause has been discovered one can restore many
>>settings.
>
>Whoa... is the "weak-sister" idea a troubleshooting step, or a general
>suggestion? One of the reasons I want SCSI is so I can hang HD and
>peripherals on one bus, freeing up interrupts... is this really bad?
---------
	Weak-sister peripherals mean just that: they don't work well
under stress. For a long time SCSI based CD-ROM players were holders
of that dubious title, but other devices contend for it. The faults
reside in the way SCSI is implemented by the vendor on their device,
plus mistakes we make in wiring the bus.
	Whether your collection continues to work well when you shove
the throttle to the floor is something to be tested. If failures then
back off some or choose better components. For what it's worth, my systems
are all SCSI and I don't have trouble mixing devices on the same bus.
	Joe D.

------------------------------

Date: Fri, 13 Jun 1997 11:22:51 +0100
From: Markus Roedel <Markus.Roedel@PRITZEL.COM>
Subject: Re: Mirrored partitions becoming un-mirrored

>We are running 2 Netware 3.12 servers with the following setup:
>A Seagate SCSI hard drive and a Quantum SCSI hard drive running off of the
>servers on-board SCSI controller, and identical Seagate and Quantum drives
>running off an Adaptec 2940UW PCI controller. This way we have duplexed the
>Seagate drives to mirror each other, and the Quantums mirror each other.
>Every 6 or 7 days we get the following message:
>
>6/10/97 11:25:10 am  Severity = 4.
>1.1.65 Device #  2 SEAGATE  ST32550W         0009 (5D010000) deactivated
>by driver due to device failure
>
>6/10/97 11:25:10 am  Severity = 4.
>1.1.85 Volume SYS still operational despite drive deactivation.
>
>6/10/97 11:25:10 am  Severity = 4.
>1.1.72 The mirrored partitions on this system are not all synchronized
>
>This error message only shows up on one of the servers. And this time it
>was hard drive device #2, which is the second Seagate. Other times it has
>been device #0, which is the first Seagate hard drive.
>
>I'm ruling out a controller problem, because the Quantums have not shown
>this message. Likewise I don't think its a hard drive problem because its
>happened to both hard drives.
>
>Could this be a random event triggered by disk activity? Or do we have a
>larger problem looming?

I had a very similar effect, which also occured only on a mirrored drive
set. In my case the problem was the SCSI-Cabling, the spec requires
connectors to be spaced min. 15 cm (abt. 0.5 foot) from each other.
On SCSI-fast systems this increases to 30 cm. Even some pre-made cables
do not always fulfill the spec. The effect only happend
in periods of high SCSI-bus load; a good test is to ncopy a large file
within the mirrored drive set. Mirroring doubles the traffic on your
SCSI-bus! Else you should be really shure to have
only one source for the TERM POWER activated and of course double check
your term settings.

------------------------------

