Re: boot failure with 4.13.0-rc6 due to ATA errors

Henrique de Moraes Holschuh
2017-08-29T16:02:16Z

On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > > > the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> > > > > command to avoid issues with buggy devices. The only downside is that
> > > > > we can't support Security Send / Receive for a device with an older
> > > > > revision due to the conflicting use of this field in earlier
> > > > > specifications.
> > >
> > > Christoph, I'm gonna revert the horkage patch and apply this one. If
> > > you can think of a better way to do this, please let me know.
> >
> > The one thing that comes to mind would be an additional patch to allow
> > people with ATA-7 to bypass the identify device data, and rely just on
> > the read log page check, based on a kernel command line parameter.
> >
> > If we get enough sucessful reports to make it worth it, an whitelist
> > could be added...
>
> If the ones we miss are the ones based on old revisions, does it
> matter? If we have to, we can just whitelist those devices and I

Well, only if the opal functionality would actually be worth something
on those old revisions I guess. It is certainly possible that it would
be better off disabled.

> don't expect there to be many.

Indeed, but we will not get much on the way of people testing this if we
don't give them a kernel parameter ;-)

--
Henrique Holschuh