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

[Tejun Heo <tj@kernel.org>]

Alan Cox wrote:
>>> Sorry you can't just blindly do this because some of the controllers snoop
>>> the SETXFER command to set their timings and whether they expect DMA. Also
>>> we've no idea if this is a bug in a specific firmware revision, a quirky
>>> pata/sata bridge or a timing problem of some sort.
>> I think it'll generally be okay for SATA unless it's bridged over to
>> PATA controller.  Any other ideas?
> 
> We seem to have one report, from one user, with one configuration, on one
> controller, using one firmware set.

There are two more reports linked from the thread.

  http://ubuntuforums.org/showthread.php?t=986871
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865

And all of them are showing the same problem.  This being a slim SATA
drive for a laptop, I don't really expect to see the drive in varied
configurations.  The problem might as well be limited to certain OEM
drive(s).

> That to me isn't meaningful evidence of anything that needs a workaround,
> beyond maybe doing what old IDE does and if a setxfer times out
> continuing in hope.

So, as far as the validity of the report goes, I think it's at
reasonable level.  Add to that my general trigger happiness toward
quirks and the machine is a VAIO and to me quirking it doesn't seem
too careless.

> (We should of course then re-read the identify pages and check the mode
> in use)

Of course, whether the workaround is proper is a completely separate
issue but unless other devices with the same problem creep up and the
device is happy with the quirk, I don't really think we should modify
the default configuration sequence for devices like this.

That said, Moritz, can you please post the output of "hdparm -I" with
and without the quirk applied?  And can you please use a preoper mail
address?

Thanks.

-- 
tejun