Xref: utzoo comp.periphs.scsi:2592 comp.unix.sysv386:8034 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!hubcap!ncrcae!ncr-sd!crash!jagat!rwhite From: rwhite@jagat.uucp (Robert White) Newsgroups: comp.periphs.scsi,comp.unix.sysv386 Subject: Re: BIG problem with 1542B and Quantum disks Keywords: scsi quantum 1542b Message-ID: <1991May13.034430.16019@jagat.uucp> Date: 13 May 91 03:44:30 GMT References: <1991May9.002915.262@wyvern.uucp> Organization: My House (no organization to speak of) Lines: 60 Ok, dumb question... do you have a driver written spesifically for the SCSI board you are using? Is it also for the UNIX Release you are using? Using the bare minimum knowlege of SCSI and the discription of your symptoms I came up with what follows. Since SCSI is a interupt-response kind of deal that allows for but does not necessarily include multiple outstanding requests (depending on the controller logic) you could be experiencing problems with instruction interleaving on the SCSI bus. The multiple drive disaster formula comes into play when a software driver is expecting a blockeing behavior our of the controller and does not get it. To Whit: Driver places a request for X:A (sector A from drive X) and returns with no data because the SCSI system is running ASYNC. Driver places another request for X:A and returns with data 'cause the previous request has returned and teh data "just happens" to be in place in the SCSI bus buffer. Everybody is happy but the system is slowed down because the lower level driver automatic retry routine is acting as a busy-wait and is actively consuming cpu during disk activity. The heavier the activity the more cpu is waiusted processing interuupts that are unnecessary. If the driver is set to do "fair scheduling" and there is more than one device on the bus, the model fails... Processor SCSI bus request data cache =============== ================ X:A --- Y:B X:A X:A Y:B Y:B X:A When the second device is added to the system the probability of consicutive requests for the same data diminish as the load reaches equal proportions across the diverse drives. NOTE: this is a simple model of asynchronus drive scheduling taken directly from some of my readings involving such matters and may not accurately represent the SCSI access methods. But it is a stock problem and it does match your symptoms. Depending on exactly how your driver is configured in its implementation it may be as simple as rebuilding your kernel with a couple of parameters jiggled. If you don't have the correct driver, and/or the board you possess isnt one of those supported by the native internals provided by the manufacturer you may just need to either a)get the driver updated by the controler manufacturer, or b) change controlers for on that is supported. -- Robert C. White Jr. | I have moved my news reading activities rwhite@jagat