Trying to image a ST9051A HDD raises some interesting questions...

12 July 2018, 13:39

I wanted to try out the new support for CHS drives over USB in WinUAE 3.6.1, so I connected a ST9051A to my Win7 x64 box via a JMicron USB to ATAPI bridge. I was also keen to image this drive since obviously it's a veteran and I don't have a backup (haven't had a P-ATA interface in my PCs for 10 years now).

First weird thing: the ST9051A appeared in Win7 Disk Management twice -- that is, two new ST9051A disks appeared, both "Unknown" / "Not Initialized" and zero bytes capacity. It also appears twice when booted into Linux, so it's not OS specific.

Anyway the disk was also listed twice in WinUAE. Once as "[RDB] [40.9M,RO]" and once as "[RDB] [40.9M,RW]". Next weird thing: no matter how many times I image it, the image file has a different MD5 hash. I've now got about 20 images (of both 'disks') with 20 different checksums. WinUAE gives the correct CHS geometry (654/4/32, 40 MB) and reports no errors when imaging, the drive "sounds" healthy, and all image files are the correct size, but looking with a hex editor and diff tools I can see random bit errors in ASCII data in some of them, but correct in others. Maybe the magnetic field has weakened in places.... I figured I could find correct versions of each block using the checksums, and stitch together a correct image. But google tells me that in FFS, data blocks don't have a checksum. Even AmigaDOS won't detect any error. So if that's the case I'm pretty screwed. ASCII files can be checked visually but, strangely I don't feel like disassembling every version of affected executables to verify the code...

Q1: anyone else seen the "disk appears twice" thing before? Is it expected behaviour with this hardware?

Q2: is there any way to test, say, an executable file for bit errors in the FFS?

Thanks in advance for any ideas or suggestions....

Toni Wilen · 12 July 2018, 21:31

Probably cause is same drive appearing as master and slave at the same time. Which possibly can explain the random data corruption. Corruption is almost guaranteed to be interface problem, data stored on platters have error correction and checksum data and errors would have caused noticeable retries/reseeks.

Did you try adjusting drive's master/slave jumper(s)?'

Q2: Unfortunately no.

13 July 2018, 13:35

Wow! Well changing the master/slave jumper fixed the "drive appears twice" problem. Thanks!

When configured as single drive (which is how I normally have it) it appears as two drives. When configured as master with a slave present, or slave with master present, it appears as one drive. Go figure.

Unfortunately I still get different images whenever I image the drive.

So far I'm taking the histogram of corresponding bytes across all image files, and sending the most frequently occurring value to the output file. The more images I take, the more accurate it should get. I get fewer disk validation errors with the resulting image (dozens instead of hundreds) so it's working, but even if I get no validation errors there's no way to be sure all the file contents are correct. Sigh.

mark_k · 13 July 2018, 14:44

How are you powering the Seagate drive? Is the USB-IDE converter powering it? The drive will need more power than a USB port is specified to supply. So that could be a possible reason for the corruption.

Have you tested the USB-IDE converter with a more modern IDE drive? It's possible the converter itself is faulty or has a defective design.

My experience with the cheapest-I-could-find USB-IDE/SATA converter was that imaging modern (40GB+) IDE drives did give corrupted data. Multiple images had differing checksums. Reading SATA drives did seem to work OK. [That was with 3.5" drives, so no power supply issue.]

Maybe the converter had too little power supply decoupling, poor PCB quality (too thin traces, poor routing), poor soldering, heat issues after extended use? And/or thin wires & traces limiting the amount of power it can supply to a connected 2.5" IDE drive.

You could try connecting the converter to a USB port on the back of your PC (as opposed to a case-front port). Also, if your USB converter has a SATA socket, try reading a SATA drive. If that works reliably, maybe you could connect an IDE-SATA converter board to the Seagate drive?

For trying to reconstruct a good image from several bad ones, you could use md5deep to get piecewise hashes of each image file.

14 July 2018, 02:25

Thanks Mark! All great advice. The drive is powered from USB through the converter, that's the only option it has for 2.5" drives, but I'm using a double-headed USB cable for power so it should be able to supply 5W. If it's lack of power I can't do much more unfortunately. The shape of the converter means I can't connect extra power.

I've used the converter on a new-ish (40GB) 2.5" P-ATA drive recently with no errors, also with 2.5" and 3.5" SATA drives. These would all be LBA addressing. Maybe the CHS implementation is badly tested on this converter, I doubt it would have been a high priority for the designers.

I downloaded md5deep, and it's making the job a lot easier so thanks! Don't suppose you have something which can click the "Create disk image" button every 5 minutes?

And I just noticed something else weird: all the errors occur in blocks at sector address 31! It affects all cylinders, all heads. What's more the distribution of errors WITHIN the affected blocks is towards the end! There are 32 sectors per track so this would be just before the heads seek? It looks like a timing problem somewhere, causing line noise to end up in the read buffer.

mark_k · 14 July 2018, 12:55

What about using a 44-to-40-pin converter like this one? You could power the drive from a proper supply and connect to the converter's 40-pin IDE port. Or how about this one which converts 44-pin IDE to SATA? I'd probably prefer that because SATA is likely to be more reliable for data transfer than IDE (if it works with the old drive & USB converter). [It might even be worth connecting the drive with SATA converter to a modern PC motherboard and seeing if it's accessible that way.]

What you noticed about the error distribution is interesting. Maybe it could be due to power issues. Are all last-in-track sectors affected? What about last-in-cylinder sectors?

I wonder... The drive probably has a read-ahead cache. After WinUAE asks to read one track's-worth of sectors (I assume the reads it issues don't cross track boundaries but didn't bother checking the source code...) and as the data is being received over USB, the drive switches heads and starts reading from the next track. If the head switch and stop-start of the read process means the drive wants more current, that could cause a voltage drop and interfere with the converter's data transfer? However, the actual/physical drive geometry probably won't match the logical one so maybe that isn't the issue.

But, if WinUAE is doing track-aligned reads, then the drive finishing reading/transferring data to the converter could also cause the current it (tries to) draw to vary. If the drive suddenly draws less current, the power supply voltage (seen by the USB converter) could rise nearer to 5V quickly, interfering with its operation?

I think it would be worth getting an adapter to allow you to power the drive separately. Even if my guesses above are wrong.

Toni Wilen · 14 July 2018, 13:09

WinUAE always read whole track in CHS mode (read with length == number of sectors)

I can change it do block by block reads, perhaps it helps or makes it worse

http://www.winuae.net/files/b/winuae.7z has above change.

15 July 2018, 13:36

Gee thanks Toni! That is awesome work. Going to try it out right away, I'll let you know how it goes

17 July 2018, 14:08

So there was no joy with the block reads. Which is really fine, it is hard for anyone to guess what might be wrong with hardware that is not sitting right in front of them! And I just appreciate the effort.

So I downloaded hardfile_win32.cpp, and hacked it into a standalone command line tool which reproduced the issue.
I wanted to try putting a delay after each disk read, in case the bridge driver is incorrectly reporting the read has finished when it is still ongoing. But the issue was still there. Some other things I tried caused the drive to seek like crazy and I stopped those pretty fast

Then I noticed that the cache buffer had plenty of spare room, so I just tried reading one extra block on each read:

do_scsi_read10_chs(h, -1, cyl, head, 1, (uae_u8*)cache, secs+1, &specialaccessmode, false);

and the problem went away.

I ran the updated tool 10 times and got 10 images all with the same checksum, and was able to copy off all files from the image in a WinUAE session, with no sign of damaged files.

So it seems like my JMicron bridge can randomly corrupt the final few bytes of each read, when in CHS passthrough mode. It has never done anything this weird reading LBA disks.

Anyway, it's a horrible hack that shouldn't be needed. And it might be just MY bridge, maybe it has overcurrent damage or firmware corruption or any other reason, who knows??. But the main thing is I got the data off the drive.

Toni Wilen · 19 July 2018, 20:21

Interesting that this kind of simple workaround "fixed" it.

But what about the very last block of drive?

I added this workaround to winuae imager. (CHS mode only). Performance isn't important and JMicron adapters are probably most common IDE adapters. (Possibly with different firmware versions?)

mark_k · 21 July 2018, 19:17

If I had to guess, reading the last sector a second time might be more likely to return the correct data. The sector data would already be in the drive's cache/buffer, so hopefully the second read would work better as the drive would draw less power (no need to activate its read circuitry).

A little wish-list for this over-read feature... Allow the user to adjust read length and overlap. E.g. set read length to 128 sectors, overlap to 8. Then WinUAE would compare the last 4KB of the previous read with the first 4KB of the next. Output warning to log if there's a mismatch to alert the user about their flaky hardware.

Larger read lengths would minimise the performance hit (and number of corrupted sectors).

(I wonder if JMicron-based adapters can return corrupted data reading from LBA-capable drives... at least the two I tested did both corrupt data then, but seemingly only occasionally, not consistently at the end of each read.)

02 August 2018, 03:28

Quote:

Originally Posted by Toni Wilen

Interesting that this kind of simple workaround "fixed" it.

But what about the very last block of drive?

Good point! I thought I'd better check.

After checking lots of images with a hex editor I can report that the last track of the image made using the workaround is exactly the same as the last track of all the other images I made without the workaround. So, the "overread" of one block past the end of the drive was accepted without any issue.

However, while re-checking the images I made BEFORE the workaround, I did notice something else interesting. The differences are not caused by random bit flips, but by INSERTED bytes -- always the 2-byte sequence FC03, always inserted right after the second byte of the last block of the track (block 31). The rest of the block is shifted right by 2 bytes, and the last 2 bytes are lost. It happens randomly every few track reads.

Does this FC03 value mean anything to anyone? Is it a known IDE command, or a continuation sequence or something? I'm mystified to how it ends up inserted into the read buffer.

02 August 2018, 03:53

Just for completeness, here's some output from a test program which compares corresponding blocks from 10 different reads of the HDD. When there's a difference in any of the 10 copies of a block, it outputs a hex dump of the first 16 bytes of each copy.

The first block is an 'LSEG' block and you can see it somtimes reads as 'LS..EG'... the second block appears to be some kind of allocation bitmap (should all be 0x6C bytes...)

Code:

Difference at block starting at: 15872 Cyl 0, Head 0, Sec 31
 --- 00: ST9051A single (master,slave present) attempt #1 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 01: ST9051A single (master,slave present) attempt #2 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 02: ST9051A single (master,slave present) attempt #3 (UNK!) [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 03: ST9051A single (master,slave present) attempt #4 (UNK!) [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 04: ST9051A single (master,slave present) attempt #5 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 05: ST9051A single (master,slave present) attempt #6 [RDB] [40.9M,RO].hdf ---
4C 53 FC 03 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD LS..EG....S..f....... ..
01 66 20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 .f J`... .L...NuH.<0*.$.
 --- 06: ST9051A single (slave to a master) attempt #1 [RDB] [40.9M,RO].hdf ---
4C 53 FC 03 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD LS..EG....S..f....... ..
01 66 20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 .f J`... .L...NuH.<0*.$.
 --- 07: ST9051A single (slave to a master) attempt #2 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 08: ST9051A single (slave to a master) attempt #3 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
 --- 09: ST9051A single (slave to a master) attempt #4 [RDB] [40.9M,RO].hdf ---
4C 53 45 47 00 00 00 80 53 FB F9 66 00 00 00 07 00 00 00 20 00 CD 01 66 LSEG....S..f....... ...f
20 4A 60 00 ED DC 20 02 4C DF 18 1C 4E 75 48 E7 3C 30 2A 01 24 00 24 48  J`... .L...NuH.<0*.$.$H
Difference at block starting at: 32256 Cyl 0, Head 1, Sec 31
 --- 00: ST9051A single (master,slave present) attempt #1 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 01: ST9051A single (master,slave present) attempt #2 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 02: ST9051A single (master,slave present) attempt #3 (UNK!) [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 03: ST9051A single (master,slave present) attempt #4 (UNK!) [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 04: ST9051A single (master,slave present) attempt #5 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 05: ST9051A single (master,slave present) attempt #6 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 06: ST9051A single (slave to a master) attempt #1 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 07: ST9051A single (slave to a master) attempt #2 [RDB] [40.9M,RO].hdf ---
6C 6C FC 03 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C ll..llllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 08: ST9051A single (slave to a master) attempt #3 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 09: ST9051A single (slave to a master) attempt #4 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
Difference at block starting at: 65024 Cyl 0, Head 3, Sec 31
 --- 00: ST9051A single (master,slave present) attempt #1 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 01: ST9051A single (master,slave present) attempt #2 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 02: ST9051A single (master,slave present) attempt #3 (UNK!) [RDB] [40.9M,RO].hdf ---
6C 6C FC 03 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C ll..llllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 03: ST9051A single (master,slave present) attempt #4 (UNK!) [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 04: ST9051A single (master,slave present) attempt #5 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 05: ST9051A single (master,slave present) attempt #6 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 06: ST9051A single (slave to a master) attempt #1 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 07: ST9051A single (slave to a master) attempt #2 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 08: ST9051A single (slave to a master) attempt #3 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
 --- 09: ST9051A single (slave to a master) attempt #4 [RDB] [40.9M,RO].hdf ---
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C llllllllllllllllllllllll
Difference at block starting at: 81408 Cyl 1, Head 0, Sec 31
 --- 00: ST9051A single (master,slave present) attempt #1 [RDB] [40.9M,RO].hdf ---

...etc etc...

mark_k · 03 August 2018, 20:19

Maybe FC03 is the address in the USB-IDE bridge chip buffer which the (next) word is going to be written to? And some power-related glitch means that address ends up in the buffer???

If you have a USB 1.1 hub, it might be interesting to connect via that, and see whether the corrupted data appears in the same place in each sector as with USB 2.0 transfers.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Still image related questions...	h0ffman	Coders. General	32	28 February 2011 18:51
restore raw hdd image	orange	support.WinUAE	0	26 February 2011 18:47
Backdrop image questions	Hobbe	support.Other	9	03 October 2007 01:21
Making image of HDD to transfer to CF	Raffaz	New to Emulation or Amiga scene	5	10 July 2007 11:08
Transfering my old migsy hdd to an image	mikos	New to Emulation or Amiga scene	4	28 May 2006 22:54

12 July 2018, 13:39	#1
Rling Posts: n/a	Trying to image a ST9051A HDD raises some interesting questions... I wanted to try out the new support for CHS drives over USB in WinUAE 3.6.1, so I connected a ST9051A to my Win7 x64 box via a JMicron USB to ATAPI bridge. I was also keen to image this drive since obviously it's a veteran and I don't have a backup (haven't had a P-ATA interface in my PCs for 10 years now). First weird thing: the ST9051A appeared in Win7 Disk Management twice -- that is, two new ST9051A disks appeared, both "Unknown" / "Not Initialized" and zero bytes capacity. It also appears twice when booted into Linux, so it's not OS specific. Anyway the disk was also listed twice in WinUAE. Once as "[RDB] [40.9M,RO]" and once as "[RDB] [40.9M,RW]". Next weird thing: no matter how many times I image it, the image file has a different MD5 hash. I've now got about 20 images (of both 'disks') with 20 different checksums. WinUAE gives the correct CHS geometry (654/4/32, 40 MB) and reports no errors when imaging, the drive "sounds" healthy, and all image files are the correct size, but looking with a hex editor and diff tools I can see random bit errors in ASCII data in some of them, but correct in others. Maybe the magnetic field has weakened in places.... I figured I could find correct versions of each block using the checksums, and stitch together a correct image. But google tells me that in FFS, data blocks don't have a checksum. Even AmigaDOS won't detect any error. So if that's the case I'm pretty screwed. ASCII files can be checked visually but, strangely I don't feel like disassembling every version of affected executables to verify the code... Q1: anyone else seen the "disk appears twice" thing before? Is it expected behaviour with this hardware? Q2: is there any way to test, say, an executable file for bit errors in the FFS? Thanks in advance for any ideas or suggestions....

12 July 2018, 21:31	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Probably cause is same drive appearing as master and slave at the same time. Which possibly can explain the random data corruption. Corruption is almost guaranteed to be interface problem, data stored on platters have error correction and checksum data and errors would have caused noticeable retries/reseeks. Did you try adjusting drive's master/slave jumper(s)?' Q2: Unfortunately no.

13 July 2018, 13:35	#3
Rling Posts: n/a	Wow! Well changing the master/slave jumper fixed the "drive appears twice" problem. Thanks! When configured as single drive (which is how I normally have it) it appears as two drives. When configured as master with a slave present, or slave with master present, it appears as one drive. Go figure. Unfortunately I still get different images whenever I image the drive. So far I'm taking the histogram of corresponding bytes across all image files, and sending the most frequently occurring value to the output file. The more images I take, the more accurate it should get. I get fewer disk validation errors with the resulting image (dozens instead of hundreds) so it's working, but even if I get no validation errors there's no way to be sure all the file contents are correct. Sigh.

13 July 2018, 14:44	#4
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	How are you powering the Seagate drive? Is the USB-IDE converter powering it? The drive will need more power than a USB port is specified to supply. So that could be a possible reason for the corruption. Have you tested the USB-IDE converter with a more modern IDE drive? It's possible the converter itself is faulty or has a defective design. My experience with the cheapest-I-could-find USB-IDE/SATA converter was that imaging modern (40GB+) IDE drives did give corrupted data. Multiple images had differing checksums. Reading SATA drives did seem to work OK. [That was with 3.5" drives, so no power supply issue.] Maybe the converter had too little power supply decoupling, poor PCB quality (too thin traces, poor routing), poor soldering, heat issues after extended use? And/or thin wires & traces limiting the amount of power it can supply to a connected 2.5" IDE drive. You could try connecting the converter to a USB port on the back of your PC (as opposed to a case-front port). Also, if your USB converter has a SATA socket, try reading a SATA drive. If that works reliably, maybe you could connect an IDE-SATA converter board to the Seagate drive? For trying to reconstruct a good image from several bad ones, you could use md5deep to get piecewise hashes of each image file.

14 July 2018, 02:25	#5
Rling Posts: n/a	Thanks Mark! All great advice. The drive is powered from USB through the converter, that's the only option it has for 2.5" drives, but I'm using a double-headed USB cable for power so it should be able to supply 5W. If it's lack of power I can't do much more unfortunately. The shape of the converter means I can't connect extra power. I've used the converter on a new-ish (40GB) 2.5" P-ATA drive recently with no errors, also with 2.5" and 3.5" SATA drives. These would all be LBA addressing. Maybe the CHS implementation is badly tested on this converter, I doubt it would have been a high priority for the designers. I downloaded md5deep, and it's making the job a lot easier so thanks! Don't suppose you have something which can click the "Create disk image" button every 5 minutes? And I just noticed something else weird: all the errors occur in blocks at sector address 31! It affects all cylinders, all heads. What's more the distribution of errors WITHIN the affected blocks is towards the end! There are 32 sectors per track so this would be just before the heads seek? It looks like a timing problem somewhere, causing line noise to end up in the read buffer.

14 July 2018, 12:55	#6
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	What about using a 44-to-40-pin converter like this one? You could power the drive from a proper supply and connect to the converter's 40-pin IDE port. Or how about this one which converts 44-pin IDE to SATA? I'd probably prefer that because SATA is likely to be more reliable for data transfer than IDE (if it works with the old drive & USB converter). [It might even be worth connecting the drive with SATA converter to a modern PC motherboard and seeing if it's accessible that way.] What you noticed about the error distribution is interesting. Maybe it could be due to power issues. Are all last-in-track sectors affected? What about last-in-cylinder sectors? I wonder... The drive probably has a read-ahead cache. After WinUAE asks to read one track's-worth of sectors (I assume the reads it issues don't cross track boundaries but didn't bother checking the source code...) and as the data is being received over USB, the drive switches heads and starts reading from the next track. If the head switch and stop-start of the read process means the drive wants more current, that could cause a voltage drop and interfere with the converter's data transfer? However, the actual/physical drive geometry probably won't match the logical one so maybe that isn't the issue. But, if WinUAE is doing track-aligned reads, then the drive finishing reading/transferring data to the converter could also cause the current it (tries to) draw to vary. If the drive suddenly draws less current, the power supply voltage (seen by the USB converter) could rise nearer to 5V quickly, interfering with its operation? I think it would be worth getting an adapter to allow you to power the drive separately. Even if my guesses above are wrong.

14 July 2018, 13:09	#7
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	WinUAE always read whole track in CHS mode (read with length == number of sectors) I can change it do block by block reads, perhaps it helps or makes it worse http://www.winuae.net/files/b/winuae.7z has above change.

15 July 2018, 13:36	#8
Rling Posts: n/a	Gee thanks Toni! That is awesome work. Going to try it out right away, I'll let you know how it goes

17 July 2018, 14:08	#9
Rling Posts: n/a	So there was no joy with the block reads. Which is really fine, it is hard for anyone to guess what might be wrong with hardware that is not sitting right in front of them! And I just appreciate the effort. So I downloaded hardfile_win32.cpp, and hacked it into a standalone command line tool which reproduced the issue. I wanted to try putting a delay after each disk read, in case the bridge driver is incorrectly reporting the read has finished when it is still ongoing. But the issue was still there. Some other things I tried caused the drive to seek like crazy and I stopped those pretty fast Then I noticed that the cache buffer had plenty of spare room, so I just tried reading one extra block on each read: do_scsi_read10_chs(h, -1, cyl, head, 1, (uae_u8*)cache, secs+1, &specialaccessmode, false); and the problem went away. I ran the updated tool 10 times and got 10 images all with the same checksum, and was able to copy off all files from the image in a WinUAE session, with no sign of damaged files. So it seems like my JMicron bridge can randomly corrupt the final few bytes of each read, when in CHS passthrough mode. It has never done anything this weird reading LBA disks. Anyway, it's a horrible hack that shouldn't be needed. And it might be just MY bridge, maybe it has overcurrent damage or firmware corruption or any other reason, who knows??. But the main thing is I got the data off the drive.

19 July 2018, 20:21	#10
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Interesting that this kind of simple workaround "fixed" it. But what about the very last block of drive? I added this workaround to winuae imager. (CHS mode only). Performance isn't important and JMicron adapters are probably most common IDE adapters. (Possibly with different firmware versions?)

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

21 July 2018, 19:17	#11
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	If I had to guess, reading the last sector a second time might be more likely to return the correct data. The sector data would already be in the drive's cache/buffer, so hopefully the second read would work better as the drive would draw less power (no need to activate its read circuitry). A little wish-list for this over-read feature... Allow the user to adjust read length and overlap. E.g. set read length to 128 sectors, overlap to 8. Then WinUAE would compare the last 4KB of the previous read with the first 4KB of the next. Output warning to log if there's a mismatch to alert the user about their flaky hardware. Larger read lengths would minimise the performance hit (and number of corrupted sectors). (I wonder if JMicron-based adapters can return corrupted data reading from LBA-capable drives... at least the two I tested did both corrupt data then, but seemingly only occasionally, not consistently at the end of each read.)

03 August 2018, 20:19	#14
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,333	Maybe FC03 is the address in the USB-IDE bridge chip buffer which the (next) word is going to be written to? And some power-related glitch means that address ends up in the buffer??? If you have a USB 1.1 hub, it might be interesting to connect via that, and see whether the corrupted data appears in the same place in each sector as with USB 2.0 transfers.