Message ID | aacba7e1001260401p539a0fb6v4758126d3f2cfc27@mail.gmail.com |
---|---|
State | Awaiting Upstream |
Delegated to: | Andy Whitcroft |
Headers | show |
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)
--- linux-2.6.32.orig/drivers/ata/libata-core.c +++ linux-2.6.32/drivers/ata/libata-core.c @@ -4250,6 +4250,9 @@ { "ST380817AS", "3.42", ATA_HORKAGE_NONCQ }, { "ST3160023AS", "3.42", ATA_HORKAGE_NONCQ }, { "OCZ CORE_SSD", "02.10104", ATA_HORKAGE_NONCQ }, + { "CRUCIAL_CT64M225", NULL, ATA_HORKAGE_NONCQ }, + { "CRUCIAL_CT128M225", NULL, ATA_HORKAGE_NONCQ }, + { "CRUCIAL_CT256M225", NULL, ATA_HORKAGE_NONCQ }, /* Seagate NCQ + FLUSH CACHE firmware bug */ { "ST31500341AS", "SD15", ATA_HORKAGE_NONCQ |