Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo <tj@kernel.org>]

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