Alan Cox wrote: >> Newly broken ones will be regressions. How many do we fix by the >> change? On SATA, setting the correct transfer chunk size doesn't seem >> to fix many. > > Regressions are not some kind of grand evil. Better to regress the odd > device than continue to break entire controllers.
We need to put more weight on regressions as it at least makes releases predictable to users. Anyways, I wasn't saying it was some absolute maxim. I was literally asking how many so that we can evaluate the trade off. >>> Tejun - instead of backing out important updates for 2.6.24 we should >>> just blacklist that specific drive for now and sort it nicely in 2.6.25, >>> not revert stuff and break everyone elses ATAPI devices. >> We'll need to blacklist setting transfer chunk size, eek, and let's >> leave that as the last resort and hope that we find the solution soon. >> Blacklist takes time to develop and temporary blacklist for just one >> release doesn't sound like a good idea. > > It seems to be sensible to me *if* it is just this one device we are > somehow confusing and that one device is holding up fixing everything > else. Yeah, if it's this one device, I fully agree. Let's see how debugging turns out. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
