Not sure why mailing list to direct this bug report to, so starting with
libata based on the error messages.
Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
fails to boot due to ATA errors:
[ 9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
[ 9.500825] ata1.00: revalidation failed (errno=-5)
[ 20.449205] ata1.00: failed to set xfermode (err_mask=0x40)
I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
v4.12 the same switch boots and 'dmesg | grep ata' shows:
[ 0.129080] libata version 3.00 loaded.
[ 1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce100 irq 27
[ 1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce180 irq 27
[ 1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce200 irq 27
[ 1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce280 irq 27
[ 1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd100 irq 28
[ 1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd180 irq 28
[ 1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.328646] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.330519] ata4: SATA link down (SStatus 0 SControl 300)
[ 1.330554] ata3: SATA link down (SStatus 0 SControl 300)
[ 1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
UDMA/133
[ 1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[ 1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 1.332717] ata1.00: configured for UDMA/133
[ 1.335813] ata6: SATA link down (SStatus 0 SControl 300)
[ 1.339829] ata5: SATA link down (SStatus 0 SControl 300)
Given the overhead of building, installing, booting and recovering from
a failed boot, 'git bisect' is not a realistic option for this switch
option unless some one can cut the span to a few iterations.
If it helps, lspci and lsscsi output from an older kernel:
# lspci
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 3 (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)
# lsscsi
[0:0:0:0] disk ATA InnoDisk Corp. - 604 /dev/sda
(cc'ing Christoph)
On Mon, Aug 28, 2017 at 12:40:39PM -0600, David Ahern wrote:
> Not sure why mailing list to direct this bug report to, so starting with
> libata based on the error messages.
>
> Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
> fails to boot due to ATA errors:
>
> [ 9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
> [ 9.500825] ata1.00: revalidation failed (errno=-5)
> [ 20.449205] ata1.00: failed to set xfermode (err_mask=0x40)
>
> I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
> v4.12 the same switch boots and 'dmesg | grep ata' shows:
>
> [ 0.129080] libata version 3.00 loaded.
> [ 1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce100 irq 27
> [ 1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce180 irq 27
> [ 1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce200 irq 27
> [ 1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce280 irq 27
> [ 1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd100 irq 28
> [ 1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd180 irq 28
> [ 1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 1.328646] ata2: SATA link down (SStatus 0 SControl 300)
> [ 1.330519] ata4: SATA link down (SStatus 0 SControl 300)
> [ 1.330554] ata3: SATA link down (SStatus 0 SControl 300)
> [ 1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
> UDMA/133
> [ 1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
> 31/32), AA
> [ 1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
> [ 1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
> [ 1.332717] ata1.00: configured for UDMA/133
> [ 1.335813] ata6: SATA link down (SStatus 0 SControl 300)
> [ 1.339829] ata5: SATA link down (SStatus 0 SControl 300)
>
> Given the overhead of building, installing, booting and recovering from
> a failed boot, 'git bisect' is not a realistic option for this switch
> option unless some one can cut the span to a few iterations.
>
> If it helps, lspci and lsscsi output from an older kernel:
>
> # lspci
> 00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
> Transaction Router (rev 02)
> 00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 1 (rev 02)
> 00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 2 (rev 02)
> 00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 3 (rev 02)
> 00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
> 00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
> 00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
> 2.0 (rev 02)
> 00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
> Enhanced Host Controller (rev 02)
> 00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA2 Controller (rev 02)
> 00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA3 Controller (rev 02)
> 00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
> 00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
> 01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)
>
>
> # lsscsi
> [0:0:0:0] disk ATA InnoDisk Corp. - 604 /dev/sda
Can you please verify whether 818831c8b22f ("libata: implement
SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit
to verify that the problem is there, and try the one prior?
Thanks.
--
tejun
On 8/28/17 1:59 PM, Tejun Heo wrote:
> Can you please verify whether 818831c8b22f ("libata: implement
> SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit
> to verify that the problem is there, and try the one prior?
That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
works fine.
Hello,
On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> On 8/28/17 1:59 PM, Tejun Heo wrote:
> > Can you please verify whether 818831c8b22f ("libata: implement
> > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit
> > to verify that the problem is there, and try the one prior?
>
> That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> works fine.
Christoph, is there anything we can do to further gate issuing of the
offending command? Otherwise, we might have to go for whitelist
instead.
Thanks.
--
tejun
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
Hello, Henrique.
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
don't expect there to be many.
Thanks.
--
tejun
On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> > On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > > ---
> > > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > > From: Christoph Hellwig <[email protected]>
> > > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> > >
> > > 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...
--
Henrique Holschuh
Hello,
On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> We could try to check the IDENTIFY DEVICE word, but given that it has
> a dual meaning in older spec versions I don't really like the idea
> either. Untested patch below as I'm not near my OPAL capable drive.
I see.
> Also most recent ATA features seem to be keyed off a log page of some
> sort, so we'll run into more problems like this.
:(
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <[email protected]>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> 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.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
David, can you please see whether this patch resolves your issue?
Thanks.
--
tejun
On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <[email protected]>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> 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.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
Applied to libata/for-4.13-fixes.
Thanks.
--
tejun
On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> ---
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <[email protected]>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> 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.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> drivers/ata/libata-core.c | 3 +++
> include/linux/ata.h | 10 +++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 697f5f896b19..ca57b03ab950 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -2413,6 +2413,9 @@ static void ata_dev_config_trusted(struct ata_device *dev)
> u64 trusted_cap;
> unsigned int err;
>
> + if (!ata_id_has_trusted(dev->id))
> + return;
> +
> if (!ata_identify_page_supported(dev, ATA_LOG_SECURITY)) {
> ata_dev_warn(dev,
> "Security Log not supported\n");
> diff --git a/include/linux/ata.h b/include/linux/ata.h
> index e65ae4b2ed48..c7a353825450 100644
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -60,7 +60,8 @@ enum {
> ATA_ID_FW_REV = 23,
> ATA_ID_PROD = 27,
> ATA_ID_MAX_MULTSECT = 47,
> - ATA_ID_DWORD_IO = 48,
> + ATA_ID_DWORD_IO = 48, /* before ATA-8 */
> + ATA_ID_TRUSTED = 48, /* ATA-8 and later */
> ATA_ID_CAPABILITY = 49,
> ATA_ID_OLD_PIO_MODES = 51,
> ATA_ID_OLD_DMA_MODES = 52,
> @@ -889,6 +890,13 @@ static inline bool ata_id_has_dword_io(const u16 *id)
> return id[ATA_ID_DWORD_IO] & (1 << 0);
> }
>
> +static inline bool ata_id_has_trusted(const u16 *id)
> +{
> + if (ata_id_major_version(id) <= 7)
> + return false;
> + return id[ATA_ID_TRUSTED] & (1 << 0);
> +}
> +
> static inline bool ata_id_has_unload(const u16 *id)
> {
> if (ata_id_major_version(id) >= 7 &&
>
That works for me.
Tested-by: David Ahern <[email protected]>
On Mon, Aug 28, 2017 at 02:22:25PM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> > On 8/28/17 1:59 PM, Tejun Heo wrote:
> > > Can you please verify whether 818831c8b22f ("libata: implement
> > > SECURITY PROTOCOL IN/OUT") is the culprit? ie. try to boot the commit
> > > to verify that the problem is there, and try the one prior?
> >
> > That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> > works fine.
>
> Christoph, is there anything we can do to further gate issuing of the
> offending command? Otherwise, we might have to go for whitelist
> instead.
We could try to check the IDENTIFY DEVICE word, but given that it has
a dual meaning in older spec versions I don't really like the idea
either. Untested patch below as I'm not near my OPAL capable drive.
Also most recent ATA features seem to be keyed off a log page of some
sort, so we'll run into more problems like this.
---
>From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <[email protected]>
Date: Tue, 29 Aug 2017 14:35:50 +0200
Subject: libata: check for trusted computing in IDENTIFY DEVICE data
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.
Signed-off-by: Christoph Hellwig <[email protected]>
---
drivers/ata/libata-core.c | 3 +++
include/linux/ata.h | 10 +++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 697f5f896b19..ca57b03ab950 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2413,6 +2413,9 @@ static void ata_dev_config_trusted(struct ata_device *dev)
u64 trusted_cap;
unsigned int err;
+ if (!ata_id_has_trusted(dev->id))
+ return;
+
if (!ata_identify_page_supported(dev, ATA_LOG_SECURITY)) {
ata_dev_warn(dev,
"Security Log not supported\n");
diff --git a/include/linux/ata.h b/include/linux/ata.h
index e65ae4b2ed48..c7a353825450 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -60,7 +60,8 @@ enum {
ATA_ID_FW_REV = 23,
ATA_ID_PROD = 27,
ATA_ID_MAX_MULTSECT = 47,
- ATA_ID_DWORD_IO = 48,
+ ATA_ID_DWORD_IO = 48, /* before ATA-8 */
+ ATA_ID_TRUSTED = 48, /* ATA-8 and later */
ATA_ID_CAPABILITY = 49,
ATA_ID_OLD_PIO_MODES = 51,
ATA_ID_OLD_DMA_MODES = 52,
@@ -889,6 +890,13 @@ static inline bool ata_id_has_dword_io(const u16 *id)
return id[ATA_ID_DWORD_IO] & (1 << 0);
}
+static inline bool ata_id_has_trusted(const u16 *id)
+{
+ if (ata_id_major_version(id) <= 7)
+ return false;
+ return id[ATA_ID_TRUSTED] & (1 << 0);
+}
+
static inline bool ata_id_has_unload(const u16 *id)
{
if (ata_id_major_version(id) >= 7 &&
--
2.11.0
On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > ---
> > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > From: Christoph Hellwig <[email protected]>
> > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> >
> > 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.
Thanks.
--
tejun