Anyone managed to permanently disable Advanced Power Management in WD10JPVX?

WD Internal Drives Desktop & Mobile Drives
41

I have been told (by “Moltke” at the HDD Oracle) that the checksum is automatically recomputed by the drive before the MOD is written to the platters. Therefore there is no need to bother with it. The only time you need to take it into account is when you are writing the module in CHS mode.

BTW, last night I confirmed that my understanding of the VSC was correct by retrieving a different section from MOD 02 in an earlier pre-ROYL model using an MHDD script.

1 Like
42

That would be better.

And thanks for testing out the MHDD VSC. I’ll check it out later just for the sake of learning.

43

The timer appears to be a 32 bit value from Offset 0x36 to 0x39. If a non-zero value is present in any of these locations, APM goes to 0x60. If we have a large value here, APM at 0x60 won’t be much different from 0x80. At 0xFFFFFFFF it’s going to be 13.5 years?

44

IIUC, the APM byte value is not actually stored anywhere. Instead it appears to be computed from the data in MOD 02.

As you say, the timer setting (?) at offset 0x36 appears to occupy 32 bits. There also appear to be 32-bit timers at offsets 0x4C (200), 0x50 (2000) and 0x54 (10).

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

00000000 00 01 98 3A 0F 0F 01 02 02 0A 01 01 0A 02 02 04
00000010 0A 00 FF FF 02 03 5A 01 1E 0A 60 08 04 40 0B 02
00000020 00 00 00 00 00 FF FF 10 00 00 00 00 03 0A 40 42
00000030 0F 00 E0 C8 10 00 C8 00 00 00 05 0A A0 0F A0 05
00000040 46 3C 02 00 05 05 B0 D0 10 00 00 00 C8 00 00 00
00000050 D0 07 00 00 0A 00 00 00 01 01 1E 64 00 10 00 00
00000060 60 27 3C 00 00 00 08

The APM values are defined in table 93, page 200, of the ATA standard:

http://nevar.pl/pliki/ATA8-ACS-3.pdf

00h Reserved
01h Minimum power consumption with Standby
02h-7Fh Intermediate power management levels with Standby
80h Minimum power consumption without Standby
81h-FDh Intermediate power management levels without Standby
FEh Maximum performance
FFh Reserved

“The APM levels may contain discrete bands (e.g., a device may implement one APM method from 80h to A0h and a higher performance, higher power consumption method from level A1h to FEh). APM levels 80h and higher do not permit the device to spin down to save power.”

45

Thanks again Franc.

I’m happy with APM 0x80 which has been the case with older 2.5" drives. I just have the phobia that excessive headparks could reduce the life of the hard disk, and don’t like the half a second delay whenever I access it after a headpark. I hate the latter more, in fact. Well offset 0x36 is similar to Idle3. The value there is the timer in 1/10th of a second. When the value is 0, the “improved APM” is effectively disabled, leaving it at 0x80.

I guess you’re right again to say that it’s computed from some variables, or hidden somewhere in Mod 02. There are simply too many 0x80 present, unless I have a stack of faulty drives to test with, I’m happy with 0x80. Gonna do some coding this weekend by modifying idle3-tools. That 32 bit value is going to be tricky since I’m not a programmer myself. Or to simplify things, just give 2 options - Disabled or 20 seconds.

I’ll checkout the timer you gave maybe in the evening. Could be meant for something, have to figure out what it is. Good day.

46

Some updates on my code :

  1. Changing Mod 02 Record 13 Offset 36 is trivial. This will enable/disable autopark at 20 seconds.

  2. Reading and writing Offsets 36-39 looks to working fine now, but my code is rather amateurish. Took me quite a while to convert the char to array (since we’re dealing with 4 bytes now instead of 1 byte in idle3) and to get it to work with pointers, but finally I got it. Verified with Nazyura’s dump.

Next TODO is to read/convert/write Offsets 36-39 from/to desiseconds. I don’t see any point setting it beyond half an hour (might as well disable it), but what the heck.

47

Nice work!

BTW, if one day you would like to play with MHDD, I have written a tutorial here:

Tutorial: Using MHDD to send ATA commands to a HDD:
http://malthus.zapto.org/viewtopic.php?t=987

48

Thanks Franc. That might be handy.

Almost there.

[root@localhost apm]#./idle3ctl -s2578103244 /dev/sdc

User input : 2578103244                < For debugging purposes
atof tmptime : 2578103244            < For debugging purposes
After parsing to timer array : cc bb aa 99    < For debugging purposes
VSC_Set_Timer 1 : 204 187 170 153        < For debugging purposes
VSC_Set_Timer 2 : -52 -69 -86 -103        < For debugging purposes
APM timer set to 257810324.4s (0xccbbaa99)
Please power cycle your drive for the new setting to take effect. A reboot will not be enough!

[root@localhost apm]#./idle3ctl -g /dev/sdc

APM timer set to 257810324.4s (0xccbbaa99)

C:>mod2dump.exe 02_99aabbcc.MOD 13
ROYL header found

Module 02 consists of 47 sections

Section 13     Length 103 bytes

Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000  00 01 98 3A 0F 0F 01 02 02 0A 01 01 0A 02 02 04
0010  0A 00 FF FF 02 03 00 01 1E 0A 60 08 04 40 0B 02
0020  00 00 00 00 00 FF FF 10 00 00 00 00 03 0A 40 42
0030  0F 00 E0 C8 10 00 CC BB AA 99 05 0A A0 0F A0 05
0040  46 3C 02 00 05 05 B0 D0 10 00 00 00 C8 00 00 00
0050  D0 07 00 00 0A 00 00 00 01 01 1E 64 00 10 00 00
0060  60 27 3C 00 00 00 00

 

Update : The first 2 bytes are meant for the APM timer. The last 2 bytes are possibly meant for spindown or whatever that makes the drive goes to Standby. By setting it to 0x000000FF the drive starts and remains in permanent Standby mode and cannot be brought up by the OS. It’s totally not recognized by Linux. hdparm -C shows that it’s in Standby after several minutes. HDAT2 also shows that it’s in standby mode with APM at 0x60.

 

hdparm -C also shows Standby for 0x0000FF00 and APM at 0x60.

 

At 0x00FF0000, hdparm -C shows it’s Active.

 

This certainly makes more sense as no one would need a few years for a timer.

1 Like
49

WD3200BEKT / March 2012

Section 13     Length 59 bytes

Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000  00 01 98 3A 0F 0F 01 02 02 0A 01 01 00 02 02 04
0010  01 00 FF FF 02 03 8A 01 1E 0A 80 08 04 40 0B 02
0020  00 E8 03 64 00 FF FF 10 00 00 00 00 01 0A 80 96
0030  98 00 C0 D8 A7 00 00 00 00 00 05

Code has been completed since over a week ago. Been busy with work while I update the idle3-tools docs before I post it to SourceForge.

50

FYI, the demo version of SeDiv for WD enables you to retrieve the drive’s resources:
http://sediv2008.narod.ru/Easy3.9Password01234567890.rar

It won’t allow you to write SA modules, though.

51

Finally, here goes nothing : http://apmtimer.sourceforge.net/

Thanks for everything Franc. I spent more time in the docs than the actual code itself.

Oh yeah, I saved the SeDiv you get, but have yet to explore it yet. Been really busy with my work. But thanks!

1 Like
52

Thanks very much for that.

In fact the feedback that you provided in this thread proved to be very useful in formulating a procedure to facilitate the recovery of data from certain WD drives with the well known “slow issue”. The fix involves modifying a single byte in MOD 02, and clearing the contents of MOD 32. Unfortunately I’m not much of a programmer, so we had to apply the fix by way of an MHDD script (plus a FreeBasic program). So far, two users have been successful. If we had not modified the firmware, it would have taken several months at 24/7 to clone the drives, assuming they could have survived the ordeal. Instead it required only a matter of hours.

It would be nice if a real programmer could produce a simple “slow-fix” tool …

53

I couldn’t have done this without your help :slight_smile:

I think I read that article somewhere in HDDguru. If you could tell me which Record and offset of Mod 02 to patch, I can make one. Clearing Mod 32 will be a bit tricky since what we currently have is Record, Offset, and bytes. I can explore further though. I can see one of my Mod 32 has 0x00 from 0x84 onwards.

And I’m not a programmer, but I could explore editing a bit of codes here and there. I’ve tried compiling with Watcom to have it running in DOS but failed. So even if I could make the code for you, it’ll be in Unix. Are you ok with that?

54

This is one of the threads I am referring to:
http://forum.hddguru.com/viewtopic.php?f=1&t=29187&start=20

The main part of the “slow fix” is to write a single byte (0x00) to section 0x1b at offset 0x02 in SA module 02.

The other part is to read MOD 32, clear certain data structures within it, and then write it back to the SA.

Perhaps a Linux tool that does the first part of the job could suffice. I could then use your proof-of-concept code to approach professional programmers to fill in the extras for us.

55

Patching Mod 02 should not be a problem.

I compared the Before and After of Mod 32. Looks like I should not touch anything between 00-8F correct? And if I were to touch that portion, it’d only be the 4 bytes of checksum. Remaining part of the mod should be zeroed out.

Let me see what I can do.

Update : I checked my list of Mod 32 (all good hard disks from 80GB - 1TB) and it appears that everything is zero from 0x84 onwards.

From your code, the 10th byte is the length of the module.

56

wrt_021b.bin :

2A 00 02 00 02 00 1B 00 02 00 01

idle3ctl / apmtimer code :

   buffer[0]=0x2a;
   buffer[2]=rw;       >>>>> Read==01 Write==02
   buffer[4]=0x02;   >>>>> Mod 02 ?
   buffer[6]=0x0d;   >>>>> 1B / Record 27
   buffer[8]=0x36;   >>>>> 02 / Offset 2
   buffer[10]=0x02; >>>>> 01 / 1 Byte

But wrt_32.bin :

08 00 02 00 32

Can you tell me what are the 3 values? Is 02 == Write and 32 == Mod 32? I can probably modify the code to something like this :

   buffer[0]=0x8;
   buffer[2]=rw;       >>>>> Read=01 Write=02
   buffer[4]=0x32;   >>>>> Mod 32 ?

57

Yes, that’s it. However, you need to first determine the size of MOD 32 and then write as many sectors back to the drive. It’s a completely different VSC. It may be best to stick with just MOD 02 and see how far we can get with it.

58

The other day I read your code and wanted to confirm if “the 10th byte is the length of the module”.

I can get Mod 02 for you in no time. It’s just a matter of altering a couple of lines in the code. We can speed things up if you could help test Mod 02 on your end. You just need to get idle3-tools and modify idle3ctl.c from :

   buffer[0]=0x2a;
   buffer[2]=rw;
   buffer[4]=0x02;
   buffer[6]=0x0d;
   buffer[8]=0x16;
   buffer[10]=0x01;

To :

   buffer[0]=0x2a;
   buffer[2]=rw;
   buffer[4]=0x02;
   buffer[6]=0x1b;  // >>>>> 1B / Record 27
   buffer[8]=0x02;  // >>>>> Offset 0x2
   buffer[10]=0x01;

Recompile and use the -g option to retrieve its value and compare against the output of Sediv or other tools.

59

My idle3ctl-modified code is able to read Mod 32’s length as well as correctly write the first 1024 bytes onto a file for backing up. For some reason, data beyond 1024 is not correctly read and thus written. Unsure if the disk is acting up since it’s a very old one. Need to solve this before I work on the write module.

60

Managed to read the whole file now. Since the 11th byte is the number of sectors, I’m curious how it handles Advanced Format drives. Do we multiply the value of byte 11 with 4096 for AF drives or still 512.

Trying to do some tests to understand “The checksum bytes are chosen so that the 32-bit little endian sum of all the 32-bit double words, including the checksum bytes, is 0x00000000”. If we have 4 bytes of 0xFFFFFFFF, does the checksum go at 0x01010101 or 0x01000000. Will try with chksum2.exe

Update : It’s the latter