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

[Tejun Heo <tj@kernel.org>]

Alan Cox wrote:
>> That isn't possible because the host machine state is unknown after a
>> timeout.  The problem is not confined to TF based controllers and even
>> on TF based controllers, it's far too dangerous to continue as nothing
>> happened.  That can easily lead to complete system lock up on quite a
>> few controllers due to fragile TF emulation layer.
> 
> It works fine on old style taskfile controllers, and the old IDE layer
> has done it for years

Yeah, exactly.  libata covers more diverse set of controllers and
nothing has ever been tested for issuing commands without full reset
after exceptions which can put HSM into unknown state.  The whole EH
is designed and implemented that way.  So, many reset methods reset
not only the ATA bus but also the HSM.  This also coincides with
hardware design.  So, if the problem is confined to TF based old IDE,
issuing commands after timeout could work fine but I don't think
that's a viable option here.

>> The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
>> just skip it.
> 
> What if there is a bridge, what if the controller needs SETXFER for
> internal use (HPT PATA with on card SATA bridges) ?

The device is horridly broken.  I don't think we can please everyone
here.  Also, it being a slim oem dvd which gets shipped with laptops,
I don't think we need to worry too much about highly varied
configurations.

> I have a feeling this is one case where there isn't a generic solution
> for all devices
> 
> For PATA we need SETXFER to be issued
> For SATA we can maybe avoid it sometimes but its getting into deeply
> undefined territory and will break the early HPT at least.

Sure, fully agreed.  It's a trade off.  There are three options.

1. Don't do anything.  The device is broken everywhere.

2. Skip SETXFER.  Any direct SATA connection to the device would work
   fine.

2. Ignore SETXFER timeout.  Probably would work for TF based
   controllers but it's largely untested for sata controllers and the
   behavior is likely undefined for more advanced controllers.

So, #2 seems like the logical choice here.  If worst comes to worst
and some idiot decides to ship the drive with SATA bridge (but really
how many of those configurations do we see anymore?), we can blacklist
that particular machine using dmi or whatnot and craft workaround such
that timeout is ignored for that particular case if it works.

Thanks.

-- 
tejun