On Tue, Aug 26 2008, Alan Cox wrote: > > a) Why was this limit put in there? It limits both transfer speed and > > request size. If it's due to some dodgy drive/bridge, perhaps we > > should just check for that and only apply the transfer limits when > > detected (or blacklisted). On the bridge setups I've seen, I've never > > had problems with killing the limit. > > Various old bridges need it - and you can't detect the bridge type. Not generically, but for some devices (like the Mtron) we can. > > b) Put in a whitelist, easy to do for these Mtron drives. > > > > c) Add a parameter to turn it on (or off, depending on the default) for > > a specific drive. > > > > I'm in favor of a) personally, but I'd like to hear why the check was > > added originally first. Dropping 20-30% of the throughput performance on > > the floor without option seems like a really bad choice. > > Can I suggest > > d) Assume the bridge is ok but teach the SATA error handling code that if > there is a timeout immediately with such a bridge then to flip down to > UDMA5 and knobble the transfer length. That would be nice, assuming that we can rely on safe behaviour (eg not data corrupting badness). -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
