MQ04ABF100 Head swap problem. No access to UA

[Lardman]

Sorry HddDonorMarket , if the problem is an overflowed G-list then a quick google shows MRT has a similar feature to PC3K in creating a virtual translator is http://us.mrtlab.com/tech/toshiba/76.html any help?

[fzabkar]

So what about my problem. lol

You haven't uploaded your G-list.

[HddDonorMarket]

So what about my problem. lol

You haven't uploaded your G-list.

Added 1st page last message at this topic

[HddDonorMarket]

Sorry HddDonorMarket , if the problem is an overflowed G-list then a quick google shows MRT has a similar feature to PC3K in creating a virtual translator is http://us.mrtlab.com/tech/toshiba/76.html any help?

I know this article. My patient drive MQ04ABF100 . its SMR . and different SA arthitecture that not solved much yet

[MasterT]

To clear the G-list, simply edit the first 16 bytes as follows:

Code:

Offset(h) 00   02   04   06   08   0A   0C   0E

00000000  5350 0000 0000 0000 0000 0000 0000 0000  SP..............

I edited as per your instructions. I press write button, says ok, but when read back still the same data as before.

Don't know if this particular drive has or not writing capability, or acelab button does nothing on this model.

Need to further test this on a good drive but do not have one right now. Maybe someone else can test this.

[Lardman]

Don't know if this particular drive has or not writing capability, or acelab button does nothing on this model.

Need to further test this on a good drive but do not have one right now. Maybe someone else can test this.

Where are you trying to write from ? I assume you don't have the menu options to work with the defects lists? If the list hasn't overflowed there shouldn't be a need to clear it.

[fzabkar]

So what about my problem. lol

You haven't uploaded your G-list.

Added 1st page last message at this topic

Sorry, I saw your first "OK again" dump but missed the follow up.

Anyway, your G-list has 0x57 defects and 0xF records, so it is not full.

[fzabkar]

Just FYI, I have extracted the CPs from your ROM. They have no bearing on your problem, as far as I can tell.

Attachments

CPs_ROM.7z

(16.42 KiB) Downloaded 978 times

[MasterT]

Where are you trying to write from ?

[MasterT]

I tried on the same drive to write a modification in DD module which of course is on the platters and it works. So drive has writing capability.

This means Acelab write button for G-list is not working on MQ04. Maybe just a leftover from previous MQ01 in the utility.

[Lardman]

MasterT You can't edit the g-list from there (or at least I couldn't find a way to) I also checked across multiple families in case it was just this drive. Take a look at the service tracks. Are you doing DR or just R&D on this drive ?

[MasterT]

Are you doing DR or just R&D on this drive ?

Actually drive is in for data recovery, but due to the fact the drive is very unresponsive, full of bad sectors, lack of proper virtual translator, and the partitions being encrypted by bitlocker, i guess this is a no go. I also tried with good head (they work in donor 100mbps +) just to make sure but still same behavior. I now try to read tracks.

[MasterT]

Cannot read any tracks on this drive. Only DE AD.

[fzabkar]

Have you tried the patient's heads in the donor?

Does you tool display the G-list defects by CHS? That would tell you whether a particular head/surface was problematic.

I have tried to manually parse the G-list, but I can't identify the head numbers. I think I can identify the track, starting sector and sector count for each record.

[fzabkar]

It seems to me that the G-list is structured something like this:

Code:

Cyl      Hd ?? Sec  Num  Type
-------- -- -- ---- ---- ----
C304F000 00 25 C00A 0800 0010  <- defect group #1
3807F000 00 25 8808 A812 0010  <- defect group #2
E50DF000 00 25 9801 9819 0010
2F10F000 00 25 900D 0800 0010
9012F000 00 25 4806 0800 0010
2513F000 00 25 8800 0800 0010
F805F000 01 25 7803 381A 0010
D505F000 01 25 C804 0800 0010
6A07F000 01 25 380D 7810 0010
670AF000 01 25 C001 F01B 0010
270DF000 01 25 C009 0800 0010
9B0CF000 01 25 3801 0800 0010
6E0EF000 01 25 C801 0800 0010
9910F000 01 25 B00E 000F 0010
1812F000 01 25 4007 7016 0010  <- last defect group

Each line represents a group of consecutive defects.

I suspect that the location of the starting sector within a group of defects is "Cyl/Hd/Sec", and the number of defects in that group is "Num".

I have only seen two "Types", and these are 0010 and 0080. I suspect that these may reflect reallocated and pending defects, but I could be wrong.

The numbers are little-endian.

In this example the bad cylinders are numbered 0xF0nnnn. I suspect that these cylinder numbers reflect the CMR cached regions rather than the SMR user area. I say this because it seems to match zones 37 - 39 in the zone table.

Code:

--------------------------------------
NN  *             Head 0             
--------------------------------------
NN  * Beg Cyl  : End Cyl  :   SPT   
--------------------------------------
00  *        0 :    10646 :   5967176
01  *    10647 :    21410 :   6032696
02  *    21411 :    32082 :   6032688
03  *    32083 :    42754 :   6032672
...
17  *   172625 :   181889 :   5573352
18  *   181890 :   191239 :   5573264
19  *   191240 :   200759 :   5573184
...
34  *   338885 :   347979 :   5572320
35  *   347980 :   356904 :   5572280
36  *   356905 :   365659 :   5572240
37  * 15729684 : 15734408 :   4918680  -> 0xF00414 / 0xF01688 / 0x4B0D98  <-- CMR cached region?
38  * 15729224 : 15729683 :   67952    -> 0xF00248 / 0xF00413 / 0x10970   <-- CMR cached region?
39  * 15728640 : 15729223 :   67952    -> 0xF00000 / 0xF00247 / 0x10970   <-- CMR cached region?
--------------------------------------

The media cache seems to span cylinders 0xF00000 - 0xF01688. The cylinders in the G-list are all within this range.

Therefore, it seems to me that the G-list consists solely of defects in the media cache, and these affect both heads.

By the way, I suspect that the real SPT is the value in the lower word of the reported SPT. For example, the real SPT for zone 37 is probably 0x0D98, rather than 0x4B0D98.

[fzabkar]

It seems to me that the G-list is structured something like this:

Code:

Cyl      Hd Zn Sec  Num  Type
-------- -- -- ---- ---- ----
C304F000 00 25 C00A 0800 0010  <- defect group #1
3807F000 00 25 8808 A812 0010  <- defect group #2
E50DF000 00 25 9801 9819 0010
2F10F000 00 25 900D 0800 0010
9012F000 00 25 4806 0800 0010
2513F000 00 25 8800 0800 0010
F805F000 01 25 7803 381A 0010
D505F000 01 25 C804 0800 0010
6A07F000 01 25 380D 7810 0010
670AF000 01 25 C001 F01B 0010
270DF000 01 25 C009 0800 0010
9B0CF000 01 25 3801 0800 0010
6E0EF000 01 25 C801 0800 0010
9910F000 01 25 B00E 000F 0010
1812F000 01 25 4007 7016 0010  <- last defect group

It just occurred to me that the third item is the Zone #. This means that the defects are confined to zone #37 (= 0x25), so it's starting to make sense.

[Lardman]

It just occurred to me that the third item is the Zone #. This means that the defects are confined to zone #37 (= 0x25), so it's starting to make sense.

Nice work - AFAICS you can't get at anything via PC3K to make any changes though.

I assume you found this ? https://forum.acelaboratory.com/viewtopic.php?f=147&t=10353&sid=4f1442400d7818d91c702c8b73acf134

I got another MQ04ABF100 out of the fuckitbucket yesterday - same symptoms, no defect list mods available , service tack access errors and initial failure reading smart. Looks to be a poorly support drive, I've bricked one of the other R&D drives - but might look at this one again later.

[fzabkar]

This is what I make of the P-list:

Code:

Offset(h) 00 01 02 03 04 05 06 07

00000000  50 4C 00 28 F2 14 20 4E  PL......
                      ^^^^^
                      number of defect records = 0x14F2 (8 bytes per record)

00000008  2E 39 10 00 02 00 00 00
00000010  00 00 00 00 FF FF 30 00  <- record #1
00000018  E8 15 00 00 FF FF 01 00
00000020  EF 15 00 00 FF FF 01 00
00000028  37 18 00 00 FF FF 01 00
00000030  7C 25 00 00 FF FF 01 00
00000038  79 26 00 00 FF FF 01 00
00000040  7D 27 00 00 FF FF 01 00
00000048  51 28 00 00 FF FF 01 00
00000050  00 00 10 00 FF FF 30 00
00000058  22 1B 10 00 FF FF 01 00
          ^^^^^ ^? ^^ ?? ?? ?? ??
            |   |  |
            |   |  zone # (byte)
            |   head # (nibble)
            cylinder # (word)

00000060  09 20 10 00 FF FF 01 00
00000068  28 20 10 00 FF FF 01 00
00000070  65 0F 00 01 FF FF 01 00
00000078  C6 19 00 01 FF FF 01 00
00000080  F5 21 00 01 FF FF 01 00
........
0000A790  84 24 10 24 FF FF 01 00
0000A798  03 0E 10 25 FF FF 21 00  <- last record (0x14F2)
0000A7A0  00 00 00 00 00 00 00 00  <- terminator record

Perhaps 0xFFFF denotes that the entire track is "slipped"?

[fzabkar]

I think I'm getting closer:

Code:

Offset(h) 00 01 02 03 04 05 06 07

00000000  50 4C 00 28 F2 14 20 4E  PL......
                   ^^ ^^^^^ ^^^^^
                   |    |     |
number of zones = 40    |    total number of records reserved for defects = 0x4E20
                        |
                      number of defect records in use = 0x14F2 (8 bytes per record)

00000008  2E 39 10 00 02 00 00 00
          ^^^^^
          number of records remaining in pool = 0x392E = 0x4E20 - 0x14F2

00000010  00 00 00 00 FF FF 30 00  <- record #1

If the P-list were full, then its size would be ...

(0x4e20 x 8) + 16 = 0x27110

The actual size is 0x28000.

[fzabkar]

Code:

Offset(h) 00 01 02 03 04 05 06 07

00000000  50 4C 00 28 F2 14 20 4E  PL......
                   ^^
                   |
number of zones = 40

The size of the P-list module is 0x28 physical sectors, so this may be an alternative explanation for the value at offset 0x03.