Re: failed command: WRITE FPDMA QUEUED with Samsung 860 EVO

[Sitsofe Wheeler <sitsofe@gmail.com>]

On Mon, 7 Jan 2019 at 07:17, Hannes Reinecke <hare@suse.de> wrote:
>
> On 1/4/19 8:33 AM, Sitsofe Wheeler wrote:
> > Blimey Laurence - you're really pushing the boat out on this one!
> >
> [ .. ]
> > I've yet to attach the disk directly to the mobo. It's a bit fiddly as
> > the most accessible port is meant for the DVD drive and I think it's
> > speed is slower than the others.
> >
> > The speed of the ATA ports is lower than you might expect (this
> > machine is fairly old):
> >
> [ .. ]
> > [    3.242623] ata2.00: FORCE: horkage modified (noncq)
> > [    3.242683] ata2.00: supports DRM functions and may not be fully accessible
> > [    3.242686] ata2.00: ATA-11: Samsung SSD 860 EVO 500GB, RVT01B6Q,
> > max UDMA/133
> > [    3.242689] ata2.00: 976773168 sectors, multi 1: LBA48 NCQ (not used)
> > [    3.245518] ata2.00: supports DRM functions and may not be fully accessible
> > [    3.247611] ata2.00: configured for UDMA/133
>
> 'slower' is an understatement.

Are you surprised that there would be such a dramatic difference in
the speeds between the two SSDs (Samsung 860 EVO, Crucial MX500) on
that particular workload in that same machine?

> That adapter can't do NCQ, hence 'WRITE FPDMA QUEUED' (which _is_ an NCQ
> command) will never be issued.
> So I'd be _very_ surprised if you still see this problem there ...

I'm curious, why would using the libata.force=2.00:noncq kernel
command line (only mentioned in my very first mail) make using that
drive more stable if the adapter could never accept that command
anyway? Shouldn't the sending of that command have been disabled if
anything along the way can't actually accept it?

-- 
Sitsofe | http://sucs.org/~sits/