Tejun Heo wrote: > Alan Cox wrote: >>>> Yes - I'd like it to just work, but I'd like it to just work without >>>> breaking anything else, without adding device specific special cases and >>>> ideally in a way that makes other stuff that is similarly odd just work >>>> too. >>> Then, how do you suggest proceeding on it? Without a bus tracer, we >>> can't easily tell what Windows is doing and on native SATA skipping >>> SETXFER isn't likely to cause any serious problem. It's basically >>> noop. >> I would suggest we issue the SETXFER always. If it times out then we will >> revalidate the identify data so we can use that to see what mode we are >> actually in. > > Hmmm... our current timeout for SETXFER is 5s, so it wouldn't be nice > but not too bad either. Alright, I'll brew up something. Hmm... There's a problem. After a timeout, libata EH always resets and reset can reset transfer mode settings and stuff, so the whole dancing becomes a bit pointless. The device in question in this case seems to retain (either that or udma/33 is the default which is unlikely) the configuration over resets but I'm skeptical how useful such logic would be generally. We can change EH logic such that it does its best to issue IDENTIFY after a SETXFER timeout without reset but that's likely to bring more problem than it solves. Some LLDs might be okay with it but there simply is no guarantee. Given the rarity, I don't think the problem warrants such major behavior change. Any more thoughts? Thanks. -- tejun -- 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
