-------------------------------------------------------------------- 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" 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 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 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 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 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 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 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." 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 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 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" 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" 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 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" 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 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 Subject: Re: Drive Deactivation ------------ 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 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: To: 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 Subject: Re: Drive Deactivation 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 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 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 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 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 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 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 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 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 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 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 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 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 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: and: ------------------------------ Date: Fri, 1 Nov 1996 13:18:17 -0500 From: Dan Schwartz Subject: Recently on this list there was a discussion of SCSI vs. IDE in a server. Below, from: 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 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 To: "NetWare 4 list" Subject: Re: EIDE VS. SCSI >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" 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 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 . 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 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 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 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 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 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 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 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 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 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 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 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 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 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. Joe D. ------------------------------ Date: Sat, 10 May 1997 08:48:19 -0600 From: Joe Doupnik 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 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. ------------------------------