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?

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

You haven't uploaded your G-list.

_________________
A backup a day keeps DR away.

Added 1st page last message at this topic

_________________
A Recovery Service In Turkey . Veri Kurtarma Türkiye https://www.digitalverikurtarma.com
Donor Drives hdddonormarket.com

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

_________________
A Recovery Service In Turkey . Veri Kurtarma Türkiye https://www.digitalverikurtarma.com
Donor Drives hdddonormarket.com

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.

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.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

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.

_________________
A backup a day keeps DR away.

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

_________________
A backup a day keeps DR away.

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.

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 ?

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

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.

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

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.

_________________
A backup a day keeps DR away.

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


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.


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.

_________________
A backup a day keeps DR away.

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.

_________________
A backup a day keeps DR away.

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.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

This is what I make of the P-list:


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

_________________
A backup a day keeps DR away.

I think I'm getting closer:


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

(0x4e20 x 8) + 16 = 0x27110

The actual size is 0x28000.

_________________
A backup a day keeps DR away.

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

_________________
A backup a day keeps DR away.