public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: "Peter Fröhlich" <peter.hans.froehlich@gmail.com>
Cc: Hannes Reinecke <hare@suse.de>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: libata-scsi: ata_to_sense_error handling status 0x40
Date: Thu, 1 Sep 2022 07:54:56 +0900	[thread overview]
Message-ID: <68bba1fd-1105-791b-433d-4917e74a0c14@opensource.wdc.com> (raw)
In-Reply-To: <CAHXXO6HZDNdsUC69COBU9MpEgkCCKJNw3OceBgW23WSAG+_wBw@mail.gmail.com>

On 8/31/22 22:30, Peter Fröhlich wrote:
> Sorry for spamming replies and quoting myself.
> 
> On Wed, Aug 31, 2022 at 12:21 PM Peter Fröhlich
> <peter.hans.froehlich@gmail.com> wrote:
>> On Wed, Aug 31, 2022 at 9:48 AM Damien Le Moal
>> <damien.lemoal@opensource.wdc.com> wrote:
>>> On 8/31/22 16:15, Hannes Reinecke wrote:
>>>> Oh, of course :-)
>>>> That was when doing SMR support for libata.
>>>> I dimly remember that some pre-spec drives had been using the DRDY bit
>>>> to signal an unaligned write. Which never made it into the spec, but the
>>>> decoding stayed.
>>>
>>> Any idea where the other bits come from ? Except for bit 5 (device fault),
>>> I do not see anything else in the specs that mandate these definitions...
>>
>> I have since discovered the "SCSI to ATA" specification which has two
>> tables about mapping ATA errors to SCSI errors. Among those I was able
>> to find an "unaligned write" case as well, but I cannot properly parse
>> the rest of the two tables yet. They are in sections 11.6 and 11.7 of
>> that document.
> 
> So I've re-read everything I can get my hands on and from what I can
> tell the overall "flow" of ata_to_sense_error() is not what the
> specifications would imply. For example we look at BSY on entry and
> then say "ah, it's set, then let's ignore the error field" when the
> specification (the way I read it) instead says "BSY is transport
> dependent, so we say nothing about it here; but check the error bit in
> status, if it is set, interpret the error field, otherwise there's
> nothing for you in the error field". Of course I am a complete noob
> when it comes to this ATA/SATA/SCSI/AHCI stuff, so please divide by at
> least two. Sorry if this adds more confusion on top.

I had a quick look at the specs again. I already spotted an error: when
the status device fault bit is set, the sense should be HARDWARE ERROR /
INTERNAL TARGET FAILURE and not ABORTED COMMAND / 0x47 like now. That is
according to SAT-5. But looking at ACS-5, sections 6 and 7.1.6, there are
*a lot* of cases that need to be taken care of. It looks like the
sense_table does that, but need to cross check.

As for the stat_table, except for the first buggy entry as mentioned
above, I have no clue where these come from. SAT only defines the HARDWARE
ERROR / INTERNAL TARGET FAILURE for when the status field device fault bit
is set. Need to dig further, but I am afraid this code may be due to years
of supporting drives returning weird errors that got mapped to sensible
sense codes instead of a pure implementation of the specs...

I need to spend some quality time with ACS and SAT documents to sort out
this one... And lots of coffee too probably :)

> 
> Cheers,
> Peter


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2022-08-31 22:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 12:00 libata-scsi: ata_to_sense_error handling status 0x40 Peter Fröhlich
2022-08-28 23:20 ` Damien Le Moal
2022-08-29  6:04   ` Peter Fröhlich
2022-08-29 23:26     ` Damien Le Moal
2022-08-30  7:02       ` Peter Fröhlich
2022-08-31  1:40         ` Damien Le Moal
2022-08-31  7:15           ` Hannes Reinecke
2022-08-31  7:48             ` Damien Le Moal
2022-08-31 10:21               ` Peter Fröhlich
2022-08-31 13:30                 ` Peter Fröhlich
2022-08-31 22:54                   ` Damien Le Moal [this message]
2022-09-01  6:10                     ` Peter Fröhlich
2022-09-01  6:13                     ` Hannes Reinecke
2022-09-02  2:35                       ` Damien Le Moal
2022-09-02  6:34                         ` Peter Fröhlich
2022-09-02  8:41                           ` Damien Le Moal
2022-09-12  7:52                             ` Peter Fröhlich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=68bba1fd-1105-791b-433d-4917e74a0c14@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=hare@suse.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=peter.hans.froehlich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox