Disable NCQ usage for Crucial M225 model range of SSDs.
Signed-off-by: Vishal Rao <[email protected]>
Tested-by: Vishal Rao <[email protected]>
Cc: [email protected]
---
Should work with 64, 128 (tested) and 256 GB capacities with any
firmware versions in
drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
filesystem corruption.
The diff is against linux kernel 2.6.33 rc5 though also meant for
2.6.32 stable series due to multiple distros' proposed long term support.
I've tested on my PC with my Crucial M225 model 128 GB SSD and it works
without the need to specify kernel boot option " libata.force=noncq ".
--- linux-source-2.6.33rc5/drivers/ata/libata-core.c.orig 2010-01-26
08:35:54.117306573 +0530
+++ linux-source-2.6.33rc5/drivers/ata/libata-core.c 2010-01-26
08:35:13.047306938 +0530
@@ -4274,6 +4274,9 @@ static const struct ata_blacklist_entry
{ "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 |
--
"Thou shalt not follow the null pointer for at its end madness and chaos lie."
> Should work with 64, 128 (tested) and 256 GB capacities with any
> firmware versions in
> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
> filesystem corruption.
If you've only tested one type why list all three ? Also you've not
listed a firmware version so do you know which are affected ?
What controllers did you test with ?
Alan
2010/1/26 Alan Cox <[email protected]>:
>> Should work with 64, 128 (tested) and 256 GB capacities with any
>> firmware versions in
>> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
>> filesystem corruption.
>
> If you've only tested one type why list all three ? Also you've not
> listed a firmware version so do you know which are affected ?
>
> What controllers did you test with ?
>
> Alan
>
The 3 IDs should match I believe and the firmware parameter is NULL.
Affected firmware versions include at least the latest 1916 and the
previous 1819, likely older ones as well.
Tested with my own Crucial CT128M225 model which has the IndiLinx
Barefoot controller.
The libata-core.c file has an existing line for "OCZ_CORESSD" for a
particular firmware version
but I suspect many, if not all of those controllers may have this issue?
At least one user of Intel SSDs reports no issues with existing
kernels and I've read that
they do NCQ right.
On Tue, Jan 26, 2010 at 09:49:18PM +0530, Vishal Rao wrote:
> At least one user of Intel SSDs reports no issues with existing
> kernels and I've read that
> they do NCQ right.
FWIW, I can confirm that both the 40 and 80 GB X25-M V2 work like
a charm on 2.6.32 here (main desktop and netbook).
Willy
On Tue, Jan 26, 2010 at 8:19 AM, Vishal Rao <[email protected]> wrote:
> 2010/1/26 Alan Cox <[email protected]>:
>>> Should work with 64, 128 (tested) and 256 GB capacities with any
>>> firmware versions in
>>> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
>>> filesystem corruption.
>>
>> If you've only tested one type why list all three ? Also you've not
>> listed a firmware version so do you know which are affected ?
>>
>> What controllers did you test with ?
>
> The 3 IDs should match I believe and the firmware parameter is NULL.
> Affected firmware versions include at least the latest 1916 and the
> previous 1819, likely older ones as well.
>
> Tested with my own Crucial CT128M225 model which has the IndiLinx
> Barefoot controller.
>
> The libata-core.c file has an existing line for "OCZ_CORESSD" for a
> particular firmware version
> but I suspect many, if not all of those controllers may have this issue?
> At least one user of Intel SSDs reports no issues with existing
> kernels and I've read that
> they do NCQ right.
A lot of different SSDs use the Indilinx Barefoot controller and the
firmware between each should be nearly identical.
Have there been any other reports of NCQ issues with similar Crucial
drives or Indilinx?
I would be hesitant to apply this branch to the trunk without seeing
at least a couple other cases of issues.
-Dave
On 01/26/2010 11:19 AM, Vishal Rao wrote:
> 2010/1/26 Alan Cox<[email protected]>:
>>> Should work with 64, 128 (tested) and 256 GB capacities with any
>>> firmware versions in
>>> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
>>> filesystem corruption.
>>
>> If you've only tested one type why list all three ? Also you've not
>> listed a firmware version so do you know which are affected ?
>>
>> What controllers did you test with ?
>>
>> Alan
>>
>
> The 3 IDs should match I believe and the firmware parameter is NULL.
> Affected firmware versions include at least the latest 1916 and the
> previous 1819, likely older ones as well.
>
> Tested with my own Crucial CT128M225 model which has the IndiLinx
> Barefoot controller.
By controller, I think Alan meant the host controller (ata_piix, ahci,
etc.)?
Jeff
2010/1/27 David Rees <[email protected]>:
> Have there been any other reports of NCQ issues with similar Crucial
> drives or Indilinx?
I haven't personally seen reports of NCQ specific issues. I have seen
people (online) reporting "issues" with Linux distro installations
hanging/freezing etc. and some prior attempts at SMART fixes which
I also initially tried but did not work for me.
I have tried to "publicise" this issue (forum, blog, mailing list posts)
in the hope more users may search and identify the correct issue
so that it may be better verified.
Unfortunately, the Crucial ID string is not model-agnostic (if thats
the right term)... meaning the patch has 3 lines to ID the 3 current
models that I know of including my own 128 GB model.
Not sure if there's a better, more generic way to match a whole group
of SSDs (same model family or various vendors) which trigger NCQ errors?
--
"Thou shalt not follow the null pointer for at its end madness and chaos lie."
2010/1/27 Jeff Garzik <[email protected]>:
> On 01/26/2010 11:19 AM, Vishal Rao wrote:
>> 2010/1/26 Alan Cox<[email protected]>:
>>> What controllers did you test with ?
>> Tested with my own Crucial CT128M225 model which has the IndiLinx
>> Barefoot controller.
>
> By controller, I think Alan meant the host controller (ata_piix, ahci,
> etc.)?
Oh I see, I have an Intel DP35DP motherboard with onboard IDE controller
with AHCI enabled. I hope thats sufficient information for now. I did read
that simply setting the mode to legacy IDE would disable NCQ there but
would disable for all drives connected.
Please let me know if further info/log files (dmesg, lspci etc) would help
and I will pastebin them...
On Tue, Jan 26, 2010 at 4:21 PM, Vishal Rao <[email protected]> wrote:
> 2010/1/27 David Rees <[email protected]>:
>> Have there been any other reports of NCQ issues with similar Crucial
>> drives or Indilinx?
>
> I haven't personally seen reports of NCQ specific issues. I have seen
> people (online) reporting "issues" with Linux distro installations
> hanging/freezing etc. and some prior attempts at SMART fixes which
> I also initially tried but did not work for me.
>
> I have tried to "publicise" this issue (forum, blog, mailing list posts)
> in the hope more users may search and identify the correct issue
> so that it may be better verified.
See, that's just the problem. I'm running couple OCZ SSD with an
Indilinx controller and also know that Mark Lord and a bunch of others
are also running them on Linux without issues. And supposedly all the
Indilinx firmware for the different resellers are based on the same
base firmware.
I did have an issue with one of them on a particular motherboard
locking up, but it turned out that the whole SATA controller was flaky
and went away after I replaced the motherboard.
So my concern is that you're proposing to black list NCQ for all users
of those particular models of SSD when it's more likely at this point
that it's a problem with your specific setup.
-Dave
2010/1/27 David Rees <[email protected]>:
> So my concern is that you're proposing to black list NCQ for all users
> of those particular models of SSD when it's more likely at this point
> that it's a problem with your specific setup.
Yes, a valid concern. I guess I didn't delve more because it's working
fine on my copy of Windows 7 RC (on the same hardware) with no sign
of error logs and pretty much the same perf as Linux with NCQ forced off.
What I can do personally is plug in my SSD into my tablet PC sitting next
to me and do a few more tests and get back to you all - it could be a couple
of days. I know its still just one user (me) reporting though.
FYI I had posted on the manufacturer's website/forums (quite active with
a lot of owners) and got NO response indicating there aren't too many
Linux users with this model - again "can't prove a negative" sort of way.
In any case, the workaround (should anyone face this issue) is to simply
add " libata.force=noncq " to the kernel boot options.
> So my concern is that you're proposing to black list NCQ for all users
> of those particular models of SSD when it's more likely at this point
> that it's a problem with your specific setup.
It could even be a Linux side bug or some kind of complicated Linux
timing thing. That *has* happened before with the older IDE stack, so we
need to be cautious, collect reports and try to see patterns before
jumping to conclusions - unless the vendor advises us otherwise.
Alan
2010/1/27 Alan Cox <[email protected]>:
> It could even be a Linux side bug or some kind of complicated Linux
> timing thing. That *has* happened before with the older IDE stack, so we
> need to be cautious, collect reports and try to see patterns before
> jumping to conclusions - unless the vendor advises us otherwise.
Good, I'm hoping you folks have better clout in soliciting responses from
users and vendors. In the mean time that I'm going to take a couple of
days to find the time to test on a different machine, here is a month-old
output of "dmesg | grep ata1" if it helps any:
http://pastebin.ubuntu.com/347122/
I'm running Ubuntu Lucid 10.04 alphas at the moment and note that even
if I "successfully reproduce" the problem on my alternate hardware, its
still the same particular disk which can't disprove that it's simply a
single defective piece - the only thing stuck in my mind is Win7rc working
fine so far while various other Linux distros have exhibited the same problem.
Vishal Rao wrote:
> 2010/1/27 Jeff Garzik <[email protected]>:
>> On 01/26/2010 11:19 AM, Vishal Rao wrote:
>>> 2010/1/26 Alan Cox<[email protected]>:
>>>> What controllers did you test with ?
>>> Tested with my own Crucial CT128M225 model which has the IndiLinx
>>> Barefoot controller.
>> By controller, I think Alan meant the host controller (ata_piix, ahci,
>> etc.)?
>
> Oh I see, I have an Intel DP35DP motherboard with onboard IDE controller
> with AHCI enabled. I hope thats sufficient information for now. I did read
> that simply setting the mode to legacy IDE would disable NCQ there but
> would disable for all drives connected.
>
> Please let me know if further info/log files (dmesg, lspci etc) would help
> and I will pastebin them...
..
Can you identify the specific Indilinx build number that your drive firmware
is based upon? If not, then at least post the identify data for us to examine:
hdparm --Istdout /dev/sd?
-ml
2010/1/27 Mark Lord <[email protected]>:
> Can you identify the specific Indilinx build number that your drive firmware
> is based upon? ?If not, then at least post the identify data for us to
> examine:
>
> ?hdparm --Istdout /dev/sd?
Thanks for taking the time on this.
I am unsure of the "specific IndiLinx firmware build number" though I've
noticed the release numbers are common for different manufacturers.
For example my disk came with the then-latest firmware "1819"
(with TRIM) which had write-perf issues then they recently released
"1916" which added TRIM and GC support (seems to work very well
I should say).
Linux logs "CRUCIAL_CT128M225" and "1916" in my dmesg, speaking
of which, here is my latest full dmesg: http://pastebin.ubuntu.com/363659/
And here is the output of hdparm --Istdout /dev/sd? :
http://pastebin.ubuntu.com/363660/
I am running the following on Kubuntu development version, uname -a is:
"Linux thunderbird 2.6.32-11-generic #16~vishalrao2 SMP Tue Jan 26
19:03:33 IST 2010 x86_64 GNU/Linux"
The " ~vishalrao2 " portion indicating it being the proposed patch -
in that good old "works for me" kind of way.
2010/1/27 Vishal Rao <[email protected]>:
> And here is the output of hdparm --Istdout /dev/sd? :
> http://pastebin.ubuntu.com/363660/
Apologies, pasting the output inline:
/dev/sda:
0c5a 3fff c837 0010 0000 0000 003f 0000
0000 0000 5335 3935 3031 352d 4146 4258
2d42 3131 3931 3936 0000 ffff 3000 3139
3136 2020 2020 4352 5543 4941 4c5f 4354
3132 384d 3232 3520 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8001
0000 2f00 4000 0200 0200 0007 3fff 0010
003f fc10 00fb 0101 c2b0 0ee7 0000 0007
0003 0078 0078 0078 0078 4000 0000 0000
0000 0000 0000 001f 0506 0000 004c 0040
01e0 0000 346b 7d01 4022 3469 3c01 4022
407f 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 c2b0 0ee7 0000 0000
0000 0000 4000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0001 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0001 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 27a5
On Tue, Jan 26, 2010 at 7:21 PM, Vishal Rao <[email protected]> wrote:
> 2010/1/27 David Rees <[email protected]>:
>> Have there been any other reports of NCQ issues with similar Crucial
>> drives or Indilinx?
>
> I haven't personally seen reports of NCQ specific issues. I have seen
> people (online) reporting "issues" with Linux distro installations
> hanging/freezing etc. and some prior attempts at SMART fixes which
> I also initially tried but did not work for me.
>
> I have tried to "publicise" this issue (forum, blog, mailing list posts)
> in the hope more users may search and identify the correct issue
> so that it may be better verified.
>
> Unfortunately, the Crucial ID string is not model-agnostic (if thats
> the right term)... meaning the patch has 3 lines to ID the 3 current
> models that I know of including my own 128 GB model.
>
> Not sure if there's a better, more generic way to match a whole group
> of SSDs (same model family or various vendors) which trigger NCQ errors?
How to define a group gets... Messy. Just as a data point, my own
Barefoot-based SSD, an OCZ Vertex, has no NCQ-related problems
whatsoever, so far as I know. Its currently hooked to a Zotac ION
board, which has ahci-driven sata controllers of some sort, was
previously in a Dell Studio Hybrid, where it also worked just fine.
--
Jarod Wilson
[email protected]
2010/1/27 Jarod Wilson <[email protected]>:
> How to define a group gets... Messy. Just as a data point, my own
> Barefoot-based SSD, an OCZ Vertex, has no NCQ-related problems
> whatsoever, so far as I know. Its currently hooked to a Zotac ION
> board, which has ahci-driven sata controllers of some sort, was
> previously in a Dell Studio Hybrid, where it also worked just fine.
Thanks for data point. I'm personally hoping for other Crucial users
specifically.
Is NCQ enabled - if you grep dmesg for ata ?
The kernel already appears to blacklist (disable NCQ for) OCZ
SSD models with firmware version "02.10104".
Vishal Rao wrote:
> http://pastebin.ubuntu.com/347122/
>
> I'm running Ubuntu Lucid 10.04 alphas at the moment and note that even
> if I "successfully reproduce" the problem on my alternate hardware, its
> still the same particular disk which can't disprove that it's simply a
> single defective piece - the only thing stuck in my mind is Win7rc working
> fine so far while various other Linux distros have exhibited the same problem.
..
The errors in that log indicate bad media.
So the question is, can you demonstrate Win7rc NOT having the same
errors when accessing the SAME (logical) sectors ?
-ml
Vishal Rao wrote:
> 2010/1/27 Jeff Garzik <[email protected]>:
>> On 01/26/2010 11:19 AM, Vishal Rao wrote:
>>> 2010/1/26 Alan Cox<[email protected]>:
>>>> What controllers did you test with ?
>>> Tested with my own Crucial CT128M225 model which has the IndiLinx
>>> Barefoot controller.
>> By controller, I think Alan meant the host controller (ata_piix, ahci,
>> etc.)?
>
> Oh I see, I have an Intel DP35DP motherboard with onboard IDE controller
> with AHCI enabled. I hope thats sufficient information for now. I did read
..
Okay, that's ICH9. I'll see if I have an ICH9 kicking around here
that I can put an OCZ/Indilinx drive onto. The current v1.5 OCZ firmware
is probably pretty close to the 1916 build version that your Crucial has.
-ml
2010/1/28 Mark Lord <[email protected]>:
> The errors in that log indicate bad media.
> So the question is, can you demonstrate Win7rc NOT having the same
> errors when accessing the SAME (logical) sectors ?
Would that mean I have to blow away my precious ext4 partitions and
have them Win7rc NTFS formatted and run a full check-disk with
bad block checking enabled?
I can do that, but probably over the weekend since I'll have to backup files
and what not.
In the mean time, can I run a linux command (please tell me what it is or
I will search for something to run online) or tool while NCQ is disabled (via
libata.force=noncq) that can do a disk scan with bad block checking?
If that linux command/tool does not show errors, will that be sufficient to
demonstrate that my disk does not have bad blocks without the need to
run Win7rc?
On Wed, Jan 27, 2010 at 3:16 PM, Vishal Rao <[email protected]> wrote:
> 2010/1/28 Mark Lord <[email protected]>:
>> The errors in that log indicate bad media.
>> So the question is, can you demonstrate Win7rc NOT having the same
>> errors when accessing the SAME (logical) sectors ?
>
> Would that mean I have to blow away my precious ext4 partitions and
> have them Win7rc NTFS formatted and run a full check-disk with
> bad block checking enabled?
No - you just need a tool to do a full read of the partition. You
could use the cygwin tools and dd, for example.
> In the mean time, can I run a linux command (please tell me what it is or
> I will search for something to run online) or tool while NCQ is disabled (via
> libata.force=noncq) that can do a disk scan with bad block checking?
badblocks <name of partition>
See the man page for more details, but that should do a read test -
may want to boot from a rescue disk or from another disk if possible
to run the test.
-Dave
2010/1/28 David Rees <[email protected]>:
>
> badblocks <name of partition>
>
> See the man page for more details, but that should do a read test -
> may want to boot from a rescue disk or from another disk if possible
> to run the test.
The first "badblocks /dev/sda7" run went ahead with no output.
Now running "badblocks -nv /dev/sda7" on this unmounted 20gb partition
and it's taking a little while for the nondestructive read+write test but
so far again no output indicating errors - will post full output shortly.
---
Yes, I'd come across this one - ran just the plain command first on
hopefully the same disk "areas" which initially had Arch and Fedora
partitions which also exhibited the same problem but I blew them away
and repartitioned/reformatted as ext4 from my ubuntu installation.
I trust (based on the man page) that badblocks re-checks any blocks
marked away by formatting (i didnt select the 'check bad blocks' option
during formatting via gparted) so the problem is not hidden?
2010/1/28 Vishal Rao <[email protected]>:
> 2010/1/28 David Rees <[email protected]>:
>>
>> badblocks <name of partition>
>>
>> See the man page for more details, but that should do a read test -
>> may want to boot from a rescue disk or from another disk if possible
>> to run the test.
>
> The first "badblocks /dev/sda7" run went ahead with no output.
here's the output, let me know if im doing something incorrect and/or
any of you need further info/testing from me:
vishal@thunderbird:~$ sudo badblocks -nv /dev/sda7 | tee badblocks.txt
[sudo] password for vishal:
Checking for bad blocks in non-destructive read-write mode
>From block 0 to 25173822
Testing with random pattern: Pass completed, 0 bad blocks found.
vishal@thunderbird:~$ cat badblocks.txt
vishal@thunderbird:~$ dmesg | grep ata1
[ 0.890636] ata1: SATA max UDMA/133 abar m2048@0xe3225000 port
0xe3225100 irq 30
[ 1.420680] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.420952] ata1.00: HPA unlocked: 250067567 -> 250069680, native 250069680
[ 1.420959] ata1.00: ATA-8: CRUCIAL_CT128M225, 1916, max UDMA/133
[ 1.420962] ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (not used)
[ 1.421629] ata1.00: configured for UDMA/133
vishal@thunderbird:~$ uname -a
Linux thunderbird 2.6.32-11-generic #16~vishalrao2 SMP Tue Jan 26
19:03:33 IST 2010 x86_64 GNU/Linux
vishal@thunderbird:~$
On Wed, Jan 27, 2010 at 11:14 AM, Vishal Rao <[email protected]> wrote:
> 2010/1/27 Jarod Wilson <[email protected]>:
>> How to define a group gets... Messy. Just as a data point, my own
>> Barefoot-based SSD, an OCZ Vertex, has no NCQ-related problems
>> whatsoever, so far as I know. Its currently hooked to a Zotac ION
>> board, which has ahci-driven sata controllers of some sort, was
>> previously in a Dell Studio Hybrid, where it also worked just fine.
>
> Thanks for data point. I'm personally hoping for other Crucial users
> specifically.
>
> Is NCQ enabled - if you grep dmesg for ata ?
$ dmesg | grep -i ncq
ahci 0000:00:0b.0: flags: 64bit ncq sntf led pmp pio slum part sxs
ata1.00: 62533296 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
> The kernel already appears to blacklist (disable NCQ for) OCZ
> SSD models with firmware version "02.10104".
Here's what I've got:
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: OCZ-VERTEX 1275, 00.P97, max UDMA/133
ata1.00: 62533296 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX 1275 00.P PQ: 0 ANSI: 5
--
Jarod Wilson
[email protected]
Mark Lord wrote:
>
> Okay, that's ICH9. I'll see if I have an ICH9 kicking around here
> that I can put an OCZ/Indilinx drive onto. The current v1.5 OCZ firmware
> is probably pretty close to the 1916 build version that your Crucial has.
..
The best I have is ICH7 and ICH8.
My OCZ/Indilinx drives all work without any issues in NCQ on those systems,
using the latest OCZ firmware -- similar vintage to your broken Crucial drive.
Cheers