On Thu, 2006-09-21 at 16:32 -0600, Moore, Eric wrote: > 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. Yes ... but I need to get back home to sort out my tree and the pending patch pile first. > > 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? I don't have one ... I actually only have 2 u80 (Quantum Atlas) and 2xu320 (Seagate Cheetah) SPI devices. I know there's a problem because I enabled QAS in the aic7xxx (u160) driver and it failed miserably on a Fujitsu when the drive tried to negotiate for it. I believe Matthew Wilcox was going to get one to try out QAS and IU on the 53c1010. > > 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. It's hard to come up with an actual user scenario where fairness would be an issue. Most users won't mix QAS and non-QAS disk devices, except for limited periods where they're upgrading or something ... I suppose there could be an issue with a tape drive on the same bus, but usually people are canny enough not to mix disk and tape either. There's really only one known field issue where QAS was a suspect ... and no-one's been able to reproduce it. James - 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
