On Wednesday, September 20, 2006 10:00 AM, James Bottomley wrote: > > Heh, Quantum Atlas ... I should have known ... > > OK, try the attached (it's a rollup of all the heuristics > changes we've > been discussing). > Thanks so much That appears to fix both issues I reported on U160 and U80 drives. Can you pls apply this to your tree for 2.6.19 push. > Actually, there are: there are some fujitsu devices that do > QAS at u160. Didn't know. Can you verify that it works with fusion with QAS enabled? > > Also, another problem is you should only enable QAS when all > > the devices on a single bus are U320(excluding safte proc). > > Meaning, if you have mixed mode case, such as U160 mixed with > > U320, you should disable QAS for all the U320 devices. > > The problem you will face is the U320 devices with QAS enabled > > are going to starve the bus, and the other devices never win > > arbitration. I've seen in my test bed using current > > spi transport. In my environment, I have two U160 devices, > > and one U320 device. Spi transport will enable > > QAS for the U320 device. > > This is a user policy thing. Usually you want QAS set where > possible to > speed up the transport ... if you're getting starvation problems, you > can disable it using the parameters. > I just don't think that is a good idea. I forsee support calls, for users that don't know they can't run QAS in mixed mode, and don't know this work around that your suggesting. Its going happen. I still think back to Andrew Patterson's request that we have a mechnism to turn one knob to shut off QAS for entire host, instead of traversing each and every target. Eric - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
