Re: SATA errors accessing hidden partitions

[Bryan Gurney <bgurney@redhat.com>]

On Tue, Sep 10, 2019 at 10:03 AM Jorge Fernandez Monteagudo
<jorgefm@cirsa.com> wrote:
>
> Hi Bryan! Thanks for your detailed answer!
>
> >Notice that logical block 524272 on devices sda3, sda4, and sda5 are
> >cited.  This is a blind guess, but are these partitions 524288 sectors
> >(256 MB) in size?
>
> No, they're 4GB partitions.
>

Oh, okay.  I'm pretty sure that blkid checks regions near the end of a
device (for example, GPT has what looks like a backup of the "EFI
PART" boot record near the end of the device).  Therefore, it may be
worthwhile to double-check the size of the partition, in case they're
not 4 GB, for some strange reason.

> >You can notice that the first few reads are near the "end" of the
> >partition.  In fact, the first two read completions are 128 sectors
> >before the end, and 16 sectors before the end.  I'm guessing that this
> >"-16" read is the one that's failing in these three partitions.
>
> Then, there is an inconsistency in the blkid and kernel communication? Why the kernel
> tries to access to a locked range? It seems that blkid ask for a sector and the kernel try
> to read it back ignoring its locked, reducing speed and trying again with no luck until
> the error is returned. This is consistent with our workaround removing blkid from the
> udev rule to avoid the error.
>
> Maybe the OPAL is not clear enough about locked ranges and kernel thinks is an error,
> or it's an error in the disk's firmware I don't know, but under windows or MacOS X no
> error is displayed.
>
> Is there some way to ask a disk for their locked ranges and patch blkid to avoid accesing them?
>

I don't know about that, but keep in mind that other programs can use
libblkid to check devices for metadata, so implementing the udev rule
may not be enough.

Here's an excerpt of the dmesg lines from the first error:

[    7.740876] ata1.00: exception Emask 0x0 SAct 0x70000083 SErr 0x0 action 0x0
[    7.740914] ata1.00: irq_stat 0x40000008
[    7.740930] ata1.00: failed command: READ FPDMA QUEUED
[    7.740951] ata1.00: cmd 60/08:00:80:27:43/00:00:03:00:00/40 tag 0
ncq dma 4096 in
                        res 41/04:00:80:27:43/00:00:03:00:00/00 Emask
0x401 (device error) <F>
[    7.741003] ata1.00: status: { DRDY ERR }
[    7.741017] ata1.00: error: { ABRT }
[    7.741154] ata1.00: supports DRM functions and may not be fully accessible
[    7.741713] ata1.00: supports DRM functions and may not be fully accessible
[    7.742121] ata1.00: configured for UDMA/133
[    7.742139] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[    7.742141] sd 0:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
[    7.742144] sd 0:0:0:0: [sda] tag#0 Add. Sense: Unaligned write command
[    7.742147] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 03 43 27 80
00 00 08 00
[    7.742149] print_req_error: I/O error, dev sda, sector 54732672
[    7.742201] ata1: EH complete

Why is there an "Illegal Request - Unaligned write command" sense
error from sd, right after the failed ata command "READ FPDMA QUEUED"?
 Is this an expected failure mode for a read to a locked range?  (I'm
not familiar with TCG Opal drives, so unfortunately I don't have
enough context.)


Thanks,

Bryan