On Mon, Aug 29, 2022 at 1:20 AM Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote: > On 2022/08/26 21:00, Peter Fröhlich wrote: > > 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. > > ... > > 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; > } > } > } That's the sense_table, I was referring to the stat_table. That table is consulted when we fail to convert via the sense_table. > 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. Which is why I am pretty sure that the "unaligned write" message is spurious since I am writing to a plain old SSD. It's going to be hard for a userspace program to generate a write that is no properly aligned for the SSD. Cheers, Peter