Anyone managed to permanently disable Advanced Power Management in WD10JPVX?

beLIEve · July 1, 2014, 2:03am

Thank you again Franc. I actually noticed the flaw when I studied the code in idle3-tools and hdparm 9.43. I also noticed that the MHDD script is missing the VSC disable command. Will explore HDDHackr as you suggested, with some old drives. The last time I tried, it extracted a few bytes up to what is needed to change the serial number and model only and not as complete as the MHDD script.

There’s a wdidle3_trace.txt file in hdparm 9.43 that’s worth taking a look in case you’re not aware. Jus sharing with you since you’re into detailed studies.

fzabkar · July 2, 2014, 8:44pm

Thanks, that’s very interesting. I wonder how much those SATA analysers cost.

ISTM that there are four VSCs. Here is my guess as to what they mean …

57 00 1a 00… — Read timer value in milliseconds (4 bytes)
57 00 1b 00… — Write timer value in milliseconds (4 bytes)

2a 00 01 00 02 00 0d 00 16 00 01 00… — Read 1 byte at offset 0x16 from section 0D of MOD 02
2a 00 02 00 02 00 0d 00 16 00 01 00… — Write 1 byte at offset 0x16 to section 0D of MOD 02

It seems that the values at offset 0x16 may not be consistent across all models and firmware. For example, I notice that when wdidle3 disables the idle3 timer (in the trace), it sets a value of 0xFC for offset 0x16 rather than 0. The idle3ctl documentation also points out the differences.

The “57” VSC appears to read (1A) and write (1B) a timer value in milliseconds, but I don’t know where this number might be stored. You may need to read all the modules, not just MOD 02, to find out. That said, idle3ctl ( http://idle3-tools.sourceforge.net)) appears to use only the second pair of VSCs.

Here is what I’ve summarised from the WDIDLE3 trace at the following URL:

https://github.com/Distrotech/hdparm/blob/master/contrib/wdidle3_trace.txt

report state of the idle3 timer:

data_out: 57 00 1a 00..
data_in: 40 1f 00 00.. ---> 0x1F40 = 8000 milliseconds
data_out: 2a 00 01 00 02 00 0d 00 16 00 01 00..
data_in: 50 00.. ---> 0x50 = 80 = 8.0 seconds

completely disable the idle3 timer:

data_out: 57 00 1b 00..
data_out: 00 00 00 00 ---> writes a value of 0 milliseconds
data_out: 57 00 1a 00..
data_in: 01 00.. ---> reads back a value of 1 millisecond ???
data_out: 2a 00 02 00 02 00 0d 00 16 00 01 00..
data_out: fc 
data_out: 2a 00 01 00 02 00 0d 00 16 00 01 00..
data_in: fc 00.. ---> 0xFC = 252


set idle3 timeout to 300 seconds:

data_out: 57 00 1b 00..
data_out: e0 93 04 00 ---> 0x493E0 = 300,000 milliseconds
data_out: 57 00 1a 00..
data_in: e0 93 04 00.. 
data_out: 2a 00 02 00 02 00 0d 00 16 00 01 00..
data&colon; 8a 
data_out: 2a 00 01 00 02 00 0d 00 16 00 01 00
data_in: 8a 00.. ---> 0x8A = 138 = 128 + 10 --> 10 x 30 = 300 seconds


change idle3 timeout to 30.5(?) seconds:

data_out: 57 00 1b 00..
data_out: 24 77 00 00 ---> 0x7724 = 30,500 milliseconds
data_out: 57 00 1a 00..
data_in: 24 77 00..
data_out: 2A 00 02 00 02 00 0D 00 16 00 01 00..
data_out: 81 
data_out: 2a 00 01 00 02 00 0d 00 16 00 01 00..
data_in: 81 00.. ---> 0x81 = 129 = 128 + 1 --> 1 x 30 = 30 seconds

beLIEve · July 3, 2014, 5:59am

You’re a genius I couldn’t figure out it was milliseconds

It seems to correspond with the code :

memset(buffer,0,sizeof(buffer));
buffer[0]=0x2a;
buffer[2]=rw;
buffer[4]=0x02;
buffer[6]=0x0d;
buffer[8]=0x16;
buffer[10]=0x01;

I’m testing idle3tools on an old drive. Offset 0x16 is consistent on old and new drives. Offset 0x1a is not 0x80 on older drives despite their APM being 0x80. I’m going to compare other mods later on.

HDDHackr did not quite work. I get checksum errors on all my drives, including those I never un-idle3 before.

fzabkar · July 3, 2014, 7:17am

I believe the following script should read offsets 0x16 and 0x1A of section 0x0D. It doesn’t write to MOD 02, so it should be safe.

; VSC enable 

reset 
waitnbsy 
regs = $45 $0b $00 $44 $57 $a0 $80 
waitnbsy

; read idle3 timer byte at offset 0x16 in section 0x0D of module 02

regs = $d6 $01 $be $4f $c2 $a0 $b0 
waitnbsy 
checkdrq 
sectorsfrom = rd_0D_16.bin 
waitnbsy 
regs = $d5 $01 $bf $4f $c2 $a0 $b0 
waitnbsy 
checkdrq 
sectorsto = 0D_16.bin

; read APM (?) byte at offset 0x1A in section 0x0D of module 02

waitnbsy
regs = $d6 $01 $be $4f $c2 $a0 $b0 
waitnbsy 
checkdrq 
sectorsfrom = rd_0D_1A.bin
waitnbsy 
regs = $d5 $01 $bf $4f $c2 $a0 $b0 
waitnbsy 
checkdrq 
sectorsto = 0D_1A.bin

; end of script

rd_0D_16.bin

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 

00000000 2a 00 01 00 02 00 0D 00 16 00 01 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
........ 
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

rd_0D_1A.bin

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 

00000000 2a 00 01 00 02 00 0D 00 1A 00 01 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
........ 
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

If you’re feeling adventurous, you might like to try reading the model number using an appropriate VSC.

beLIEve · July 3, 2014, 7:51am

Thanks again Franc. What I mean is, my 160gb and 250gb does not have 0x80 in offset 0x1a. Only the 1TBs have 0x60 (WD10JPVX) and 0x80 (WD10JPVT) respectively there which we’ve already determined.

Since tools like hdparm are reporting 0x80 for APM even with the 160gb, it has got to be stored in some mods. So I need to find a unique mod/location where the 160gb, 250gb, and WD10JPVT has 0x80 and WD10JPVX has 0x60.

If newer models use different mods and offsets based on what we’ve tested earlier, well, I can’t risk testing on my 1TB I need to find the mod and offset for the older models that I can play with.

fzabkar · July 3, 2014, 8:12am

ROYL models have a 32-bit checksum, whereas pre-ROYL drives with Marvell MCUs have an 8-bit checksum.

Type “chksum2 -32 mod02.bin”.

If you would like me to confirm or recalculate the checksum, then upload your UNDO.BIN file (with your edits).

As for where the APM byte is stored, I’m not sure I can help you. You could use NazYura’s tools to retrieve all the MODs, but what do you do then? Perhaps you could compare all the MODs before and after running WDIDLE3. This will hopefully enable you to locate where the “57” VSC command wrote its “millisecond” timer values. Perhaps the APM byte will be nearby???

beLIEve · July 3, 2014, 9:07am

Thanks Franc. Yes I’m trying to figure out the location of the APM setting, and also hoping that it’s near the idle3 setting. Stay tuned

fzabkar · July 3, 2014, 9:50am

The demo version of WDMarvel has a ModDescr.ini file that briefly describes the function of each of the modules. The file also contains a “Desc2” section that indicates the importance of each module. For example, those that are flagged with a “B” are required for the normal operation of the drive. “SelfScan” refers to factory testing and calibration. These modules are not needed.

http://www.users.on.net/~fzabkar/temp/ModDescr_Eng.ini
http://www.users.on.net/~fzabkar/temp/ModDescr.ini

beLIEve · July 3, 2014, 11:15am

WDMarvel does not seem to work on my computer. Even my 1TB hard disk is detected at 0. Other disks are undetected, might be due to AHCI. Can’t boot up if I disable AHCI. Anyway, I did a full dump with NazYura’s on my 160gb with Idle3 disabled and 8 seconds. The following mods were changed : 02h, 20h, 21h, 22h, 6Fh. Comparing them now.

Based on ModDescr_Eng.ini, I can ignore 20-22. So back at the drawing board for Mod 02

Update : Acoustics Management is written to Mod 02 Record 3 offset 0Ah on 160GB. Change from hdparm is persistent.

beLIEve · July 3, 2014, 6:26pm

I think we’ll have to end here. I’ve searched around and the only other WD10 2.5" Mod 02 available is the one given by you.

The only consistency (same Record and Offset) between WD10JPVT (APM 0x80) and WD10JPVX (APM 0x60) is Record Number 13 offset 0x1A. Perhaps if we could have more samples in the future, we can explore further. There are simply too many 0x80 entries present in Mod 02 of old drives to test with, imagine each one could render the drive dead.

I was thinking of modifying the idle3ctl.c code to have the APM value written to the hard disk but unfortunately, older drives do not seem to use Record 13 offset 0x1A for APM. Checked 500GB made in 2009 and 160GB/250GB made in 2010. I do not want to risk my brand new 1TBs for this experiment of course.

I appreciate all the help, time, and guidance you’ve given, Franc (sorry that I remembered your name wrong in earlier posts - I’ve corrected them). If you’ve no further inputs, I’ll mark one of your answers as the solution.

fzabkar · July 3, 2014, 11:54pm

NazYura’s tools were written for the older pre-ROYL models. The module IDs in those drives were limited to a single byte, ie 01h to FFh. Current drives have 2-byte MOD IDS. Having said that, it appears unlikely that the millisecond timer would be written to these higher numbered MODs, given their descriptions. The only other potential location might be the “ROM” (the serial flash memory chip at U12 on the PCB). However, I think this would be unlikely also. NazYura does have a tool for reading the ROM, though.

I don’t know what MOD 6F does, but don’t be surprised if it doesn’t checksum to 0. This happens with good drives with no history of problems.

Thanks for the feedback regarding the AAM setting. It fills in another piece in the jigsaw puzzle.

FWIW, ISTM that each section of MOD 02 remains consistent between earlier and later models. By that I mean that newer models appear to retain the MOD 02 structure of earlier models in that they append new records rather than redefining the existing ones.

For example, we can see the similarities in record 3 of MOD 02 for the following drives:

WD3200AAKS-00L9A0

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 00 01 A4 0A 00 00 00 00 07 7F B0 00 06 B0 04 01
00000010 20 01 00 00 9A 01 64 00 00 00 00 21 0A 32 00 00
00000020 00 32 00 00 00 00 01 00 00 00 00 0A A0 0F 00 00
00000030 00 80 3E

WD10JPVT-75A1YT0

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 00 01 A0 10 00 04 00 00 07 7F 00 00 06 28 0A 01
00000010 00 01 00 00 1E 05 64 00 00 00 00 20 0A 14 00 00
00000020 00 14 00 00 00 01 08 00 00 00 00 0A A0 0F 00 00
00000030 00 BC 34 00 00 00 00 10 01 00 02 1E 1E 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 01 AC 0D 00 00 80
00000050 01 88 13 88 13 00 02 E0 2E 00 01 00 00 00 00 D5
00000060 0B 64 00 80 38 01 00 64 00 90 01 00 00 05

WD2002FAEX-00MJRA0

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 00 01 A0 00 00 04 00 00 07 7F 00 00 06 73 08 01
00000010 00 01 00 00 9A 05 64 00 00 00 00 20 0A 14 00 00
00000020 00 14 00 00 00 00 00 00 00 00 00 0A A0 0F 00 00
00000030 00 BC 34 00 00 00 00 10 00 00 02 1E 1E 00 00 00
00000040 00 00 00 00 00 00 00 00 00 00 00 AC 0D 00 00 80
00000050 00 88 13 88 13 02 02 E0 2E 00 01 00 00 00 00 D5
00000060 0B 64 00 80 38 01 00 64 00 90 01 00 00 00 00 00
00000070 00 00 00 00 00 FE 01 05 00 00 00 00 00 00 00

ISTM that one could possibly break down section 3 into its component records by examining the evolution of MOD 02 between models. For example, offsets 6Eh - 7Eh appear to constitute a new record.

Some of the numbers look interesting …

offset 0Dh

0x04B0 = 1200
0x0A28 = 2600
0x0873 = 2163

offset 31h

0x3E80 = 16000
0x34BC = 13500

offset 4Bh

0x0DAC = 3500

offsets 51h and 53h

0x1388 = 5000

offsets 57h

0x2EE0 = 12000

beLIEve · July 4, 2014, 9:13am

WD5000LPVX-22V0TT0 made in Nov 2013. 8 seconds Idle3 and APM 0x60.

Record 13 From offset 0 : 0001983A0F0F0102020A01010A0202040A00FFFF020350011E0A60

Could the new 0x60 APM value been made patchable like Idle3 as a fallback plan in case the frequent parks results in a high RMA?

If the location of Idle3 changes due to evolution, we’ll have to understand the Sata trace how wdidle3.exe identifies its location through the queries. Then from there, determine the instructions to obtain APM.

Update : The contents of Mod 02 are almost identical between WD5000LPVX and WD10JPVX.

fzabkar · July 5, 2014, 3:10am

Your guess is as good as mine.

I would expect that the ATA Identify Device command gets most of its information from MOD 02, so there may be some value in comparing the two data sets. Otherwise I’m out of ideas.

beLIEve · July 7, 2014, 6:22am

Just did some test with the old 500gb by modifying the idl3ctl code, it’s not Mod 02 Record 13 offset 0x1a. I’m going to compare Mod 01 later.

fzabkar · July 7, 2014, 7:39am

MOD 01 is a directory. The following article is my attempt to understand the structure of MOD 01 in pre-ROYL Marvell models. The ROYL version has some similarities.

Analysis of MOD 01 - Western Digital WD2500BB-55RDA0:
http://malthus.zapto.org/viewtopic.php?f=59&t=184

beLIEve · July 8, 2014, 10:43am

Thanks Franc. From your studies of Mod 01, seems unrelated.

Some further observation :

By disabling Idle3, it takes 20 seconds to autopark on idle.
Using hdparm to change APM to 0x7f yields the same 20 seconds as 0x60.

Update 1 :

WD10JPVT APM 0x80 Record 6 : 0001020602000002060000060400030200160001020602000002030000060600050A0016
WD10JPVX APM 0x60 Record 6 : 000102060200000206000006040003020016600001020602000002030000060600050A001660

WD1600BEVS APM 0x80 Record 6 : 0001020602000002060000060400030200160001020602000002030000060600050A0016
WD2500BEVS APM 0x80 Record 6 : 0001020602000002060000060400030200160001020602000002030000060600050A0016
WD5000BEVT APM 0x80 Record 6 : 0001020602000002060000060400030200160001020602000002030000060600050A0016

WD10EADS No APM Record 6 : 0001020602000002060000060400030200160001020602000002030000060600050A0016

WD5000LPVX APM 0x60 : Mod 02 almost identical with WD10JPVX

WD10JPVX Record 4 0001010040004001320005070001000280003C008000008008100A050A242E425F78808000080005800002000306000800040F000E0000050800800100028000040003050000010100C800800432000507000100028000C8008000008008100A050A14285F5F78808000080005800002000C06000800100F000E0000050800800100048000040010050000010100C800FFFF32000507000100028000C8008000008008100A050A14285F5F78808000080005800002001007000C00100F001C0000050800800100048000040018050000010100C800FFFF32000507000100028000C8008000008008100A050A14285F5F78808000080005800002001008001800
WD10JPVT Record 4 0001010040004001320005070001000280003C008000008008100A050A242E425F78808000080005800002000306000800040F000E0000050800800100028000040003____00010100C800800432000507000100028000C8008000008008100A050A14285F5F78808000080005800002000C06000800100F000E0000050800800100048000040010____00010100C800FFFF32000507000100028000C8008000008008100A050A14285F5F78808000080005800002001007000C00100F001C0000050800800100048000040018____00010100C800FFFF32000507000100028000C8008000008008100A050A14285F5F78808000080005800002001008001800400F00380000

WD10JPVX Record 12 00016002120022000A000000000000010100
WD10JPVT Record 12 00015502280022000A000000000000030100

WD10JPVX Record 13 0001983A0F0F0102020A01010A0202040A00FFFF020300011E0A600804400B020000000000FFFF1000000000030A40420F00E0C81000C8000000050AA00FA005463C02000505B0D010000000C8000000D00700000A00000001011E640010000060273C00000008
WD10JPVT Record 13 0001983A0F0F0102020A01010A0202040100FFFF020350011E0A800804400B020000000000FFFF1000000000010A40420F00E0C8100000000000050AA00F0505B0D0100090010000D0070000000000000200
I’ve changed 0x60 to 0x80 on an old 500GB but APM stays at 0x60, so this is not the correct location.

WD10JPVX Record 39 000101005802001032000507000100028000C8008000008008100A050A14285F5F78808000080005800002001008000800600F003800000508008001000480000400180500
WD10JPVT Record 39 00010100C800001032000507000100028000C8008000008008100A050A14285F5F78808000080005800002001008000800600F00380000050800800100048000040018

WD10JPVX Record 41 000100E80360EAE803000014
WD10JPVT Record 41 0001000A003200E093040014

Summary : Records 4, 12, 39 and 41 are unlikely used for APM. Studying Records 6 and 13 now.

Update 2 :

Changed Record 6 offset 0x12 from 0x60 to 0x80, APM stays at 0x60. Idle3ctl was unable to read offset 0x25, so I couldn’t change it.

Changed Record 13 offset 0x60 from 0x60 to 0x80, APM stays at 0x60.

beLIEve · July 14, 2014, 11:52am

WD5000BPVT-60HX2T3 Apr 2012 - Idle3 4 secs - APM 0x80

Mod 02 Record 13 : 0001983A0F0F0102020A0101000202040100FFFF020228011E0A80

fzabkar · July 15, 2014, 9:20am

I wrote a small utility to parse MOD 02:

http://www.users.on.net/~fzabkar/MOD2DUMP.7z

I have tested it with ROYL and Marvell (pre-ROYL) models. Hopefully it will be of some use to you. It is written in FreeBASIC. I have included the source code (I am not a programmer, so it will probably look ugly to someone who is).

beLIEve · July 15, 2014, 11:46am

Thanks a lot Franc. It just might be

I did some experiment yesterday with an old drive. I can actually apply Idle3 on a desktop Blue and it starts to autopark.

So far all the desktop drives I tried has Mod 02 Record 13 Offset 1A as 00, possibly indicating that they don’t support APM. I’ve also tried changing that byte to 00 and FE, but APM remains at 0x60 and autopark persists. I must be missing something important. Perhaps I should start checking for the 20 seconds value, be it 0x14 (20) or 0xC8 (200).

beLIEve · July 17, 2014, 6:02am

Good news Franc. Your tool certainly simplified my work. It’s Record 13 Offset 0x36. This offset is present in the LPVX 500GB but not the BPVT 500GB. So I figured there is a high probability that this is the 0xC8 I should be looking at.

So I changed idle3ctl.c to

memset(buffer,0,sizeof(buffer));
buffer[0]=0x2a;
buffer[2]=rw;
buffer[4]=0x02;
buffer[6]=0x0d;
buffer[8]=0x36;
buffer[10]=0x01;

[root@localhost apm]# ./idle3ctl -g /dev/sdb
Idle3 timer set to 200 (0xc8)

Preliminary tests reveal that setting it to 100 does not affect the autopark timer and APM stays at 0x60 after a power cycle.

[root@localhost apm]# ./idle3ctl -d /dev/sdb
Idle3 timer disabled

After a power cycle :

[root@localhost apm]# hdparm -I /dev/sdb | grep power
Advanced power management level: unknown setting (0x0080)

The LCC does not increase too. A lot of Linux users would be grateful to you Now I’ll go figure out how to correct the checksum although idle3util does not seem to do that.