WDC WD2000FYYZ compatibility issues with SATA II controller

My WD2000FYYZ-01UL1B1 (SATA III) is connected to an “older” SATA II controller, hardware see [1] below.

In auto-negotiation link speed is only set to SATA I (1.5 GB/s), Windows and Linux same behaviour. Using this SATA I mode I get on a certain Operationg system UDMA CRC errors according to SMART when copying big amount of data with many kworker processes (its a Linux system), log excerpt see below at [2]. Disabling NCQ resolves this.

After I learned that jumpering pin 5 & 6 on the WD force the drive into SATA II, auto-negotiation connects as SATA II (3 GB/s link speed). But this even worsened things as now after some minutes I got temporary freezes for 5-20 seconds now on all operating systems (Windows and Linux) as the WD didn’t respond. Querying status by SMART at that time did show weird info or just hangs.

On Amazon buyers reviews the Western Digital “WDC WD2000FYYZ-01UL1B1” one called it a “diva”, or more technical, the HDD controller (or its firmware) does not work well with controllers in SATA I and SATA II mode. (its in German language): http://www.amazon.de/product-reviews/B0090UFNR6/ref=cm_cr_dp_see_all_summary/277-5621623-3411642?ie=UTF8&showViewpoints=1&sortBy=byRankDescending

==> So my questions:

  • is this a known issue (from the SATA standards it should work with a SATA II controller)?
  • is there any way to resolve this (especially, is there a firmware update)?
  • Or any other hints appreciated

Additional Info:

[1] Hardware: Intel Core 2 Duo E6850, MSI P6N SLI with nForce 650 SLI / Nvidia nForce 430i Chipset, 8 Gbyte RAM

I tested different cables and SATA ports: nochange. My old Samsung Spinpoint SATA II HDD works just fine (double-checked).

[2] log on Linux shows these entries in SATA I linkspeed with NCQ on while copying big amount of data to disk:

(Sorry for the length - I haven’t found a way to attach a file)

2015-01-11T21:17:29.197102+01:00 linux-os131b64 udisksd[2461]: Mounted /dev/sdg1 at /run/media/user/Lexar on behalf of uid xxxx
2015-01-11T21:17:29.199943+01:00 linux-os131b64 org.gtk.Private.UDisks2VolumeMonitor[2350]: ### debug: emit_signal: 0xa768d0
2015-01-11T21:19:36.238308+01:00 linux-os131b64 kernel: [14936.666646] ata3: EH in SWNCQ mode,QC:qc_active 0x7FFFFFFF sactive 0x7FFFFFFF
2015-01-11T21:19:36.238323+01:00 linux-os131b64 kernel: [14936.666650] ata3: SWNCQ:qc_active 0x1000 defer_bits 0x7FFFEFFF last_issue_tag 0xc
2015-01-11T21:19:36.238324+01:00 linux-os131b64 kernel: [14936.666650] dhfis 0x1000 dmafis 0x1000 sdbfis 0x0
2015-01-11T21:19:36.238325+01:00 linux-os131b64 kernel: [14936.666653] ata3: ATA_REG 0x41 ERR_REG 0x84
2015-01-11T21:19:36.238326+01:00 linux-os131b64 kernel: [14936.666655] ata3: tag : dhfis dmafis sdbfis sactive
2015-01-11T21:19:36.238326+01:00 linux-os131b64 kernel: [14936.666657] ata3: tag 0xc: 1 1 0 1  
2015-01-11T21:19:36.238327+01:00 linux-os131b64 kernel: [14936.666668] ata3.00: exception Emask 0x1 SAct 0x7fffffff SErr 0x400000 action 0x6 frozen
2015-01-11T21:19:36.238328+01:00 linux-os131b64 kernel: [14936.666669] ata3.00: Ata error. fis:0x21
2015-01-11T21:19:36.238329+01:00 linux-os131b64 kernel: [14936.666671] ata3: SError: { Handshk }
2015-01-11T21:19:36.238330+01:00 linux-os131b64 kernel: [14936.666674] ata3.00: failed command: WRITE FPDMA QUEUED
2015-01-11T21:19:36.238331+01:00 linux-os131b64 kernel: [14936.666678] ata3.00: cmd 61/00:00:80:fa:77/04:00:2b:00:00/40 tag 0 ncq 524288 out
2015-01-11T21:19:36.238331+01:00 linux-os131b64 kernel: [14936.666678] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error)
2015-01-11T21:19:36.238332+01:00 linux-os131b64 kernel: [14936.666680] ata3.00: status: { DRDY ERR }
2015-01-11T21:19:36.238333+01:00 linux-os131b64 kernel: [14936.666681] ata3.00: error: { ICRC ABRT }
2015-01-11T21:19:36.238334+01:00 linux-os131b64 kernel: [14936.666683] ata3.00: failed command: WRITE FPDMA QUEUED
2015-01-11T21:19:36.238335+01:00 linux-os131b64 kernel: [14936.666686] ata3.00: cmd 61/00:08:80:fe:77/04:00:2b:00:00/40 tag 1 ncq 524288 out
2015-01-11T21:19:36.238336+01:00 linux-os131b64 kernel: [14936.666686] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error)
2015-01-11T21:19:36.238337+01:00 linux-os131b64 kernel: [14936.666688] ata3.00: status: { DRDY ERR }
2015-01-11T21:19:36.238337+01:00 linux-os131b64 kernel: [14936.666689] ata3.00: error: { ICRC ABRT }
2015-01-11T21:19:36.238338+01:00 linux-os131b64 kernel: [14936.666691] ata3.00: failed command: WRITE FPDMA QUEUED
2015-01-11T21:19:36.238339+01:00 linux-os131b64 kernel: [14936.666694] ata3.00: cmd 61/00:10:80:02:78/04:00:2b:00:00/40 tag 2 ncq 524288 out
2015-01-11T21:19:36.238339+01:00 linux-os131b64 kernel: [14936.666694] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error)
2015-01-11T21:19:36.238340+01:00 linux-os131b64 kernel: [14936.666696] ata3.00: status: { DRDY ERR }
2015-01-11T21:19:36.238341+01:00 linux-os131b64 kernel: [14936.666697] ata3.00: error: { ICRC ABRT }
2015-01-11T21:19:36.238342+01:00 linux-os131b64 kernel: [14936.666698] ata3.00: failed command: WRITE FPDMA QUEUED
2015-01-11T21:19:36.238343+01:00 linux-os131b64 kernel: [14936.666702] ata3.00: cmd 61/00:18:80:06:78/04:00:2b:00:00/40 tag 3 ncq 524288 out
2015-01-11T21:19:36.238343+01:00 linux-os131b64 kernel: [14936.666702] res 41/84:60:80:f6:77/84:00:2b:00:00/40 Emask 0x10 (ATA bus error)
2015-01-11T21:19:36.238344+01:00 linux-os131b64 kernel: [14936.666703] ata3.00: status: { DRDY ERR }
2015-01-11T21:19:36.238345+01:00 linux-os131b64 kernel: [14936.666705] ata3.00: error: { ICRC ABRT }
**************[EDITED: repeated 15 times with different tags]*************************
2015-01-11T21:19:36.238492+01:00 linux-os131b64 kernel: [14936.666923] ata3: hard resetting link
2015-01-11T21:19:36.238492+01:00 linux-os131b64 kernel: [14936.666924] ata3: nv: skipping hardreset on occupied port
2015-01-11T21:19:36.706212+01:00 linux-os131b64 kernel: [14937.132042] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
2015-01-11T21:19:36.722463+01:00 linux-os131b64 kernel: [14937.148817] ata3.00: configured for UDMA/133
2015-01-11T21:19:36.722509+01:00 linux-os131b64 kernel: [14937.148979] ata3: EH complete
2015-01-11T21:23:10.075315+01:00 linux-os131b64 udisksd[2461]: Cleaning up mount point /run/media/user/Lexar (device 8:97 is not mounted)

Hello,

I wouldn’t say that is a know issue since theres no oficial documentation about any specific issue downgrading the transfer speed of the unit to make it compatible with SATA II

This units are designed to work with SATA III. However, they should work on a SATA II motherboard

My recommendation on this case, is to test the unit on a different board and also with the WD DLG Tool

Link to DLG Tool

http://wdc.custhelp.com/app/answers/detail/a_id/940/session/L3RpbWUvMTQyNTUwMjA3My9zaWQvZWdpdk11Z20%3D

I tested several times now with the WD-Diag tool on an auto negotiated SATA 1 connect - passed, no errors. I haven’t done the test with jumpered pins 5&6 for SATA II mode, as it wouldn’t make sense, and i fear to corrupt data using it.

I don’t have another PC by hand now to test the drive on another hardware. I still think there is a kind of incompatibility at least with my Nvidia nforce SATA controller, and maybe two other SATA 2 controllers as the Amazon buyers review test results suggests. Maybe it’s a tricky timing problem in communication producing timeouts.

I will try some more test and even get another new SATA cable. Or maybe get me a SATA 3 controller card, but have to find one that works on Linux. So some update maybe laters here.

Found that one (see the comments section they discuss about this WD2000FYYZ):

http://www.amazon.co.uk/review/R3HH3PPBL37O2N

See comments of “The Tester”, Quote:

“I would not ultimately say that the WD2000FYYZ fails on _any_ 3G controller. As a matter of fact, it does fail with _some_ 3G controllers. And when this happens, the trouble is that the system does not completely reject the drive, but everything seems good for hours but later it may hang the entire computer or scramble part of the data _at random_
This is a special issue of that drive type. I have not seen anything like this before. For example, the equivalent WD1003FBYZ 1TB/6G drive, works in the same 3G environment without flaw. Normally 6G drives are 3G compatible, but not this one. It is simply a firmware bug of that particular model.”

Anyone having ideas or suggestions?