neese@adaptx1.UUCP (05/11/91)
>I need help in a big way. > >I've started having problems with my UNIX system since I installed an >Adaptec AHA-1542B and two Quantum SCSI disks: a ProDrive 210S and a ProDrive >105S, both internal. I'm running with the following h/w & s/w: >Zeos 386/20, 8MB RAM, no coprocessor, generic VGA card. >Microport SysV/386 r3.2.2 with the Columbia Data Products driver set. > >I'm experiencing the following symptoms: > >When both drives are installed and mounted doing: >find <drive1> -depth -print | cpio -pd > <drive2> >will hang the system after a random but small number of copies. The disks >will seem to slow down for a few seconds, until they come to a complete halt >from which there is no return save the reset button. The second disk is >totally unusable. As long as I'm only accessing one disk, everything works. I do not know about Microport or the Columbia drivers, but I do know what is causing the floppy problem. The drivers have either failed to reprogram the bus on and off times or they have incorrectly programmed the bus on and off time of the adapter. By default the adapter uses 11 micro-seconds on and 4or 5 off. This is fine in a single threaded environment, but what happens in a multi-user environment is: The floppy DMA will be starved. The only way around this is to program the bus on time to 7 micro-seconds or less. The bus off time will be fine at 4 micro-seconds. This will allow enough time for the floppy DMA to be done without starving it. >When only the 210S is mounted, the system will run, but disk throughput >seems slow, and when there is intense disk activity (like when news is being >processed), keyboard response is agonizingly slow while waiting for the >disk. Sometimes it takes more than a minute for a response. Also, even >with only one drive mounted, I've noticed that when using the floppy >(with cpio for instance), the floppy head will do wierd seeks, like it got >a read error and is retrying, when there is SCSI disk activity. I'm >running the floppy off the 1542B. > >The AHA-1542B is configured as follows: >SCSI id 7 >Synchronous transfer enabled >SCSI parity enabled >DMA channel 5 >DMA request 5 >DMA acknowledge 5 >Interrupt channel 11 >DMA speed 5MB/s >Adaptec bios enabled >bios base addr DC00 >auto sense enabled > >The drives are configured as SCSI id 0 & 1, with parity enabled. I've got >terminators on the 1542B and the farthest drive from the card (the 105S). > >Can anyone tell me what my problem could be? Microport can't. Alliance >Peripheral Systems (my retailer) can't. I've got a 105MB doorstop right >now that I need to make useful. At to the other issues. I can attest to the Quantums peacefully co-existing on the SCSI bus as I have an exact duplicate on one of my systems here and it chugs along just fine. It is running SCO UNIX, and has also been run on ISC 2.2 and SCO XENIX. No problems here. Given this, I would probably guess the problem is the Columbia drivers, but that is only a guess. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
press@venice.SEDD.TRW.COM (Barry Press) (05/13/91)
In article <283400107@adaptx1> neese@adaptx1.UUCP writes: >I do not know about Microport or the Columbia drivers, but I do know what >is causing the floppy problem. The drivers have either failed to reprogram >the bus on and off times or they have incorrectly programmed the bus on and >off time of the adapter. By default the adapter uses 11 micro-seconds on and >4or 5 off. This is fine in a single threaded environment, but what happens >in a multi-user environment is: The floppy DMA will be starved. The only >way around this is to program the bus on time to 7 micro-seconds or less. >The bus off time will be fine at 4 micro-seconds. This will allow enough >time for the floppy DMA to be done without starving it. I'm wondering if this relates to a problem I've seen running FASTBACK under DOS. I have a Northgate 25MHz 486, with a 1542B, Maxtor 200MB drive, and one each 3.5 and 5.25 floppy. When I run FASTBACK with the processor on at full speed, it's lucky to manage a track per minute or so. If I slow the processor down, then FASTBACK runs mostly normally, but the transfer rate to the floppy is still less than I've seen on a true blue AT. Is it possible that the problem you mentioned is affecting this as well? What are the "right" bus timings under DOS (5) for this machine? Are there disk vs. floppy speed trades by making changes? Thanks. -- Barry Press Internet: press@venice.sedd.trw.com
neese@adaptx1.UUCP (05/16/91)
>In article <283400107@adaptx1> neese@adaptx1.UUCP writes: >>I do not know about Microport or the Columbia drivers, but I do know what >>is causing the floppy problem. The drivers have either failed to reprogram >>the bus on and off times or they have incorrectly programmed the bus on and >>off time of the adapter. By default the adapter uses 11 micro-seconds on and >>4or 5 off. This is fine in a single threaded environment, but what happens >>in a multi-user environment is: The floppy DMA will be starved. The only >>way around this is to program the bus on time to 7 micro-seconds or less. >>The bus off time will be fine at 4 micro-seconds. This will allow enough >>time for the floppy DMA to be done without starving it. > >I'm wondering if this relates to a problem I've seen running FASTBACK under >DOS. I have a Northgate 25MHz 486, with a 1542B, Maxtor 200MB drive, and >one each 3.5 and 5.25 floppy. When I run FASTBACK with the processor on >at full speed, it's lucky to manage a track per minute or so. > >If I slow the processor down, then FASTBACK runs mostly normally, but the >transfer rate to the floppy is still less than I've seen on a true blue AT. > >Is it possible that the problem you mentioned is affecting this as well? >What are the "right" bus timings under DOS (5) for this machine? Are there >disk vs. floppy speed trades by making changes? FASTBACK is definately effected by this. That is why I wrote SETSCSI. It allows you to reprogram the above parameters under DOS, so you can get the full speed of programs such as FASTBACK. I have usually made a batch file that puts SETSCSI infront of FASTBACK and then calls SETSCSI again after FASTBACK to restore the values. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
press@venice.SEDD.TRW.COM (Barry Press) (05/20/91)
In article <283400112@adaptx1> neese@adaptx1.UUCP writes: >FASTBACK is definately effected by this. That is why I wrote SETSCSI. It Great. Thanks for the info. Now, at the risk of sounding uninformed, can you point me to an ftp site for setscsi and scsicntl please? (And, I hope, it's not simtel, since it's nearly impossible to get through to there!) -- Barry Press Internet: press@venice.sedd.trw.com