From: arno@natisbad.org (Arnaud Ebalard)
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Marc Carino <marc.ceeeee@gmail.com>, Tejun Heo <tj@kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Andrew Lunn <andrew@lunn.ch>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
willy tarreau <w@1wt.eu>, Jason Cooper <jason@lakedaemon.net>
Subject: Re: [BUG,REGRESSION] SATA regression on 12.0-rc4 kernel
Date: Wed, 09 Oct 2013 10:40:26 +0200 [thread overview]
Message-ID: <8761t6bzwl.fsf@natisbad.org> (raw)
In-Reply-To: <CADLC3L3EYU0VSfLMYjo013jSTWm4yZw24y+4HdvOOoEkOc6uhQ@mail.gmail.com> (Robert Hancock's message of "Tue, 8 Oct 2013 23:50:33 -0600")
Robert Hancock <hancockrwd@gmail.com> writes:
>> With two different disks (same model though, i.e. 250GB 3.5" WD blue), it
>> consistently works on a 3.11.4 and consistently fails on 3.12-rc3 and
>> 3.12-rc4 (not tested others 3.12-rc). The problem is easy to reproduce,
>> i.e. I just need to perform some disk operations. With the two commits
>> reverted from 3.12-rc4, I can consistently do a "find / -exec sha256sum
>> '{}' \;" w/o anything happening.
>>
>> What I do not understand is why the log report failed FPDMA commands if
>> the feature is supposed to be SSD-related (looking only at commit
>> messages: 87fb6c31b9 seems SSD-related, ed36911c74 does not). Is it
>> possible that the feature detection is what is causing the issue? Or
>> that the hardware report support w/o having? I can test with a different
>> disk if you think it would help.
>
> The commands that are failing are WRITE FPDMA QUEUED which is a
> regular NCQ write command. The ones that these commits add support for
> are FPDMA_SEND and FPDMA_RECV which are used for NCQ trim commands.
>
> It's possible that the feature detection for this is picking up
> support for FPDMA SEND/RECV on this drive when it shouldn't be. Can
> you post the output of "hdparm --Istdout /dev/sdX" for one of these
> drives (where X matches the drive in question)?
Will do that tonight and post the output.
a+
WARNING: multiple messages have this Message-ID (diff)
From: arno@natisbad.org (Arnaud Ebalard)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG,REGRESSION] SATA regression on 12.0-rc4 kernel
Date: Wed, 09 Oct 2013 10:40:26 +0200 [thread overview]
Message-ID: <8761t6bzwl.fsf@natisbad.org> (raw)
In-Reply-To: <CADLC3L3EYU0VSfLMYjo013jSTWm4yZw24y+4HdvOOoEkOc6uhQ@mail.gmail.com> (Robert Hancock's message of "Tue, 8 Oct 2013 23:50:33 -0600")
Robert Hancock <hancockrwd@gmail.com> writes:
>> With two different disks (same model though, i.e. 250GB 3.5" WD blue), it
>> consistently works on a 3.11.4 and consistently fails on 3.12-rc3 and
>> 3.12-rc4 (not tested others 3.12-rc). The problem is easy to reproduce,
>> i.e. I just need to perform some disk operations. With the two commits
>> reverted from 3.12-rc4, I can consistently do a "find / -exec sha256sum
>> '{}' \;" w/o anything happening.
>>
>> What I do not understand is why the log report failed FPDMA commands if
>> the feature is supposed to be SSD-related (looking only at commit
>> messages: 87fb6c31b9 seems SSD-related, ed36911c74 does not). Is it
>> possible that the feature detection is what is causing the issue? Or
>> that the hardware report support w/o having? I can test with a different
>> disk if you think it would help.
>
> The commands that are failing are WRITE FPDMA QUEUED which is a
> regular NCQ write command. The ones that these commits add support for
> are FPDMA_SEND and FPDMA_RECV which are used for NCQ trim commands.
>
> It's possible that the feature detection for this is picking up
> support for FPDMA SEND/RECV on this drive when it shouldn't be. Can
> you post the output of "hdparm --Istdout /dev/sdX" for one of these
> drives (where X matches the drive in question)?
Will do that tonight and post the output.
a+
next prev parent reply other threads:[~2013-10-09 8:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-06 21:38 [BUG,REGRESSION] ARM: mvebu: SATA regression w/ 12.0-rc4 kernel Arnaud Ebalard
2013-10-07 12:59 ` Jason Cooper
2013-10-07 19:12 ` [BUG,REGRESSION] SATA regression on " Arnaud Ebalard
2013-10-08 2:38 ` Robert Hancock
2013-10-08 2:38 ` Robert Hancock
2013-10-08 6:10 ` Arnaud Ebalard
2013-10-08 6:10 ` Arnaud Ebalard
2013-10-09 5:50 ` Robert Hancock
2013-10-09 5:50 ` Robert Hancock
2013-10-09 8:40 ` Arnaud Ebalard [this message]
2013-10-09 8:40 ` Arnaud Ebalard
2013-10-09 15:22 ` Marc (Marc-Angelo) Carino
2013-10-09 15:22 ` Marc (Marc-Angelo) Carino
2013-10-09 18:56 ` Arnaud Ebalard
2013-10-09 18:56 ` Arnaud Ebalard
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=8761t6bzwl.fsf@natisbad.org \
--to=arno@natisbad.org \
--cc=andrew@lunn.ch \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregory.clement@free-electrons.com \
--cc=hancockrwd@gmail.com \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=marc.ceeeee@gmail.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tj@kernel.org \
--cc=w@1wt.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.