Patch to disable NCQ for some SSD drives

Hello,

Please see LP: #502219 about problems with Crucial brand SSDs.
Also my original msg to LKML: http://lkml.org/lkml/2010/1/22/3

I'm just starting out to learn PPA work:
https://launchpad.net/~vishalrao/+archive/kernels

Patch is something like this (should I attach the diff to the bug?):





(Please CC me in any replies since I'm not subscribed to the list)

Regards,
Vishal

On Tue, 2010-01-26 at 17:31 +0530, Vishal Rao wrote:
> Hello,
> 
> Please see LP: #502219 about problems with Crucial brand SSDs.
> Also my original msg to LKML: http://lkml.org/lkml/2010/1/22/3
> 
> I'm just starting out to learn PPA work:
> https://launchpad.net/~vishalrao/+archive/kernels
> 
> Patch is something like this (should I attach the diff to the bug?):

You should send the patch to the ATA maintainer,
Jeff Garzik <jgarzik@pobox.com>, and cc linux-ide@vger.kernel.org .
At the end of the patch description, add these lines:

Signed-off-by: Vishal Rao <vishalrao@gmail.com>
Cc: stable@kernel.org

Ben.

2010/1/26 Ben Hutchings <ben@decadent.org.uk>:
> You should send the patch to the ATA maintainer,

Thanks, patch sent with an initial (not so encouraging) response
from Alan Cox:

http://lkml.org/lkml/2010/1/26/185
http://lkml.org/lkml/2010/1/26/202

Should the patch be rejected, might Ubuntu incorporate it (in
essence) for the benefit of users who shouldn't be dismayed at
their new SSDs' breakage the way I was? :-)

Would be nice to have for the quality of LTS Lucid I would think...

In any case, the workaround is to pass " libata.force=noncq "
as part of the kernel boot options which I think is already
mentioned in LP: #502219 .

On Tue, 2010-01-26 at 23:39 +0530, Vishal Rao wrote:
> 2010/1/26 Ben Hutchings <ben@decadent.org.uk>:
> > You should send the patch to the ATA maintainer,
> 
> Thanks, patch sent with an initial (not so encouraging) response
> from Alan Cox:
> 
> http://lkml.org/lkml/2010/1/26/185
> http://lkml.org/lkml/2010/1/26/202
> 
> Should the patch be rejected, might Ubuntu incorporate it (in
> essence) for the benefit of users who shouldn't be dismayed at
> their new SSDs' breakage the way I was? :-)

It's not my decision - I'm actually on the Debian kernel team and trying
to work together with other distros on the 2.6.32 stable branch.

> Would be nice to have for the quality of LTS Lucid I would think...
[...]

It might be nice for you, but the response you're getting suggests that
this is not a generally correct fix.

Ben.

Vishal Rao wrote:
> 2010/1/26 Ben Hutchings <ben@decadent.org.uk>:
>> You should send the patch to the ATA maintainer,
> 
> Thanks, patch sent with an initial (not so encouraging) response
> from Alan Cox:
> 
> http://lkml.org/lkml/2010/1/26/185
> http://lkml.org/lkml/2010/1/26/202
> 
> Should the patch be rejected, might Ubuntu incorporate it (in
> essence) for the benefit of users who shouldn't be dismayed at
> their new SSDs' breakage the way I was? :-)
> 
> Would be nice to have for the quality of LTS Lucid I would think...
> 
> In any case, the workaround is to pass " libata.force=noncq "
> as part of the kernel boot options which I think is already
> mentioned in LP: #502219 .
> 

The responses I saw there rather sounded like the patch just cures a symptom for
you. Others seem to have working cases with NCQ. It might be something generic
but yet not understood or related to the controller instead of the drive.
So blacklisting the drive is not the solution. There seem to be people willing
to help with debugging further but only can do that when they got help with the
actual data (iow from you ;-)).
All in all it did just not sound as this is ready for general consumption.

-Stefan

2010/1/27 Stefan Bader <stefan.bader@canonical.com>:
> The responses I saw there rather sounded like the patch just cures a symptom for
> you. Others seem to have working cases with NCQ. It might be something generic
> but yet not understood or related to the controller instead of the drive.
> So blacklisting the drive is not the solution. There seem to be people willing
> to help with debugging further but only can do that when they got help with the
> actual data (iow from you ;-)).
> All in all it did just not sound as this is ready for general consumption.

Fair enough. It *is* more of a workaround rather than a real fix and an easy
workaround would be the kernel boot option anyway. As rightly pointed out
by one of the folks, it may just be me so no point changing stuff for all.

I'll try to provide as much info as I can to them, and hope more
users (or not) might report issues.

(No concern for me personally, I'm happy that it works well for me already)