On 2022/08/26 21:00, Peter Fröhlich wrote:
> Apologies if this is the wrong place.
>
> In commit 8ae720449fca4b1d0294c0a0204c0c45556a3e61 "libata: whitespace
> fixes in ata_to_sense_error()" we find, among many actual whitespace
> changes, another change that adds an entry for 0x40 to the stat_table.
>
> I thought that 0x40 is bit 6 of the ATA status which means (I think)
> "drive ready" and not, as we translate here, "unaligned write
> command". I may be very much confused about this, but if so, please
> tell me how.
See the code below that table definition. You can see this hunk:
if (drv_err) {
/* Look for drv_err */
for (i = 0; sense_table[i][0] != 0xFF; i++) {
/* Look for best matches first */
if ((sense_table[i][0] & drv_err) ==
sense_table[i][0]) {
*sk = sense_table[i][1];
*asc = sense_table[i][2];
*ascq = sense_table[i][3];
goto translate_done;
}
}
}
So the first field of the table defines the *error* bits, not the status. You
can check the ACS specs (Section 10.3 of ACS6-r1) to see that bit 6 of the error
field for an error output is "UNCORRECTABLE ERROR bit" for the commands READ DMA
Ext, Read Log Ext, Read PIO, Read Stream, SMART Read log, Read PIO Extended and
NCQ Read.
So this code is per specs.
> (I've been tracking another, presumably unrelated, error and have the
> impression that this "unaligned write" message has been leading me in
> the wrong direction.)
Are you using an SMR drive ? Getting an aligned write should not happen for a
regular disk as the kernel ensure alignments of IO to LBAs. But for SMR, it is
possible to send a write command that is not aligned to a zone write pointer
position, resulting in an unaligned write error.
--
Damien Le Moal
Western Digital Research
