linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Hannes Reinecke <hare@kernel.org>,
	"kernel-team@fb.com" <kernel-team@fb.com>
Subject: Re: [PATCH] libata: don't request sense data on !ZAC ATA devices
Date: Mon, 24 Jun 2019 21:59:34 +0000	[thread overview]
Message-ID: <BN8PR04MB581297B07BB104D3D3E85464E7E00@BN8PR04MB5812.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20190624205708.GS657710@devbig004.ftw2.facebook.com

Tejun,

On 2019/06/25 5:57, Tejun Heo wrote:
> Hello, Damien.
> 
> On Mon, Jun 24, 2019 at 08:27:02PM +0000, Damien Le Moal wrote:
>> For NCQ commands, I believe it is mandatory to request sense data for the failed
>> command to get the device out of error mode. So isn't this approach breaking
> 
> Hah, that's a news to me.  We never had that code path before ZAC
> support was added, so I'm kinda skeptical that'd be the case.

I checked again the ACS specs, and your are right, REQUEST SENSE DATA EXT is
optional in general, dependent on support of the Sense Data Reporting feature set.

For NCQ command errors, from ACS:

"If an error occurs while the device is processing an NCQ command, then the
device shall return command aborted for all NCQ commands that are in the queue
and shall return command aborted for any subsequent commands, except a command
from the GPL feature set (see 4.10) that reads the NCQ Command Error log (see
9.13), until the device completes that command without error."

So as long as NCQ command error log page is read, the device queue will get out
of error mode and new commands can be issued. There is no need for REQUEST SENSE
DATA EXT. I got confused with the fact that the Sense data reporting feature is
mandatory with ZAC drives (that is defined in ZAC, not ACS).

>> anything for well behaving drives ? Wouldn't it be better to blacklist the
>> misbehaving SSD you observed the problem with ?
> 
> Provided I'm not wrong with the assumption, there's virtually no
> benefit in doing this and that's gonna be a *really* difficult
> blacklist to develop.

You are not wrong :)
Will test your patch on our test rig which generates (in purpose) a lot of
command failures on ZAC drives. We can also give it a run with generated errors
on regular disks.

Cheers.

> 
> Thanks.
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2019-06-24 21:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 16:32 [PATCH] libata: don't request sense data on !ZAC ATA devices Tejun Heo
2019-06-24 20:27 ` Damien Le Moal
2019-06-24 20:57   ` Tejun Heo
2019-06-24 21:59     ` Damien Le Moal [this message]
2019-06-25  6:05 ` Hannes Reinecke
2019-06-25 12:25 ` Damien Le Moal
2019-06-25 15:35 ` Jens Axboe

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=BN8PR04MB581297B07BB104D3D3E85464E7E00@BN8PR04MB5812.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hare@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=tj@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).