Data corruption problems copying files

Calgor · 18 June 2009, 13:08

I am having intermittent data problems while transferring files. Sometimes it only happens on large files, other times I am not sure if it also happens on medium size files.

Setup:
A1200 Blizzard IV 030/50 + SCSI Kit + SCSI-IDE + IDE-SDHC + SDHC 16GB (only 1 scsi device on chain with ID 0)
OS3.9BB2 1MB ROM + scsi 43.45
1230scsi.device 8.5
MaxTransfer = 0x1FE00
TransferMask = 0x7FFFFFFE
Active termination on Acard SCSI-IDE adapter using its jumper.
SFS 1.276 / FFS OS3.9BB2 45.13

The item with the problem is the SDHC card when copying files to it (from PCMCIA slot CF card or from Ram Disk), and possibly also reading files from it. When using only CF0 and RAM there are no problems.

More than half the time on large files there is a problem. The larger the file the much more likely there is to be a problem. Results are different each time the file is copied. I check the 80MB file using GetCRC from aminet.

Here is an example of one file with errors. The file is the same size as original, but some bytes are zeroes, and others are incorrect. There is a definite pattern, probably related to MaxTransfer or something. I compiled the below list of hex file locations with differences with assistance of "fc /b" command in vista command prompt.

f0200-f0400 (zeroed)
f0401-fffff (wrong)
15d0200-15d0400 (zeroed)
15d0401-15dffff (wrong)
2ad0200-2ad0400 (zeroed)
2ad0401-2adffff (wrong)
3d20200-3d20400 (zeroed)
3d20401-3d2ffff (wrong)
5180200-5180400 (zeroed)
5180401-518ffff (wrong)

The number of bytes zeroed in each instance is just about 512, and the number of incorrect bytes (including zeroed) is about 65536-512. For the last 3 error ranges, the gap between them is even the same (2ad0200-3d20200-5180200 19MB gaps).

Is this indicative of a bad cable, bad termination, wrong maxtransfer or something else?

Loedown · 18 June 2009, 13:56

Greetings,
I would ask how old the PCMCIA card is, as they use flash technology, which has a finite life, 1000 read / write cycles.

I know from experience that these sorts of problems will be rather obscure, I really wish you well with this one.

I might also suggest looking at the HDD ribbon cable to ensure it hasn't rubbed through and allowed some wires to be randomly grounded etc.

Calgor · 18 June 2009, 14:12

Hi Lowdown thanks, but not sure which card you are asking about. The problem is independent of the PCMCIA slot (and the card therein) It happens when copying from RAM to the SDHC card.

If it is the SDHC card you are asking about, it is virtually brand new I got it a short while ago.

The SCSI chain is about 30cm long from SCSI Kit to 25-50 pin adapter to Acard adapter which is the end of the chain. There is also an IDE cable from Acard adapter to IDE-SDHC adapter which is about 5cm long. Both are self-made cables.

SCSI Kit -> 30cm 25pin cable -> 25-50pin adapter -> 5cm 50pin cable -> Acard SCSI-IDE Adapter (active termination) -> 5cm 40pin IDE cable -> IDE-SDHC adapter with 16GB SDHC card

So yes, a problem with the chain is a possibility.

Calgor · 18 June 2009, 14:28

Very strange.

I changed the Mask to 0x0FFFFFFC and MaxTransfer to 0xFE00 and now the computer is crashing and rebooting in the middle of copying files!

But it was successful for the FFS partition but big problems in SFS partition. Stay tuned...

Calgor · 18 June 2009, 14:41

Well the computer will not even boot now unless I disable all the HD partitions in the boot menu. Back to the drawing board wipe the whole SD card and start again. Not the first time since the SFS 1.275 debacle and the FastATA MK-III bug debacles. Who know what the problem was this time. I will only use FFS until it is stable this time.

If someone can please look at the first post and suggest what may be causing that pattern of errors in the files.

Anemos · 18 June 2009, 16:46

Similar problem here before change my PSU with bigger/Watt/amp.
Test another PSU.

alexh · 18 June 2009, 17:28

Your SCSI->IDE adapter should handle all the max transfer issues. You could try a higher more SCSI-esque value. But it shouldn't make a difference.

I'll research what the "Mask" field actually does (if anything).

Toni Wilen · 18 June 2009, 17:51

if ((mask & address) == address) -> memory address can be used for data transfer. At least it is supposed to work like this

0x0FFFFFFC mask means Blizzard's fast ram can't be used (it is located at 0x68000000). Pointless mask in any case, usually mask is used to limit transfers to 24-bit fast ram only (for example A590/A2091 DMA is 24-bit only), 0x00fffffc or chip ram only which is 0x001ffffc.

EDIT: with incompatible mask driver should either fall back to PIO or use separate DMA compatible buffer + CPU transfer (not sure if this is implemented in all drivers..)

alexh · 18 June 2009, 17:56

Interesting stuff.

Calgor · 18 June 2009, 18:08

Hmm.. I knew the Mask limited the area of memory which can be used (from those DosDriver mountlists), but did not add 1+1 to figure that value excludes the fastram on Blizzard. So that was not very useful but should not have been the cause for the computer to crash.

Anyway, I have now reformatted the SD card in the PC so now the Amiga boots up with it - RDB or something must have been corrupted to make it worse than a non-formatted drive causing amiga not to be able to boot even when trying to boot off floppy.

Next step is to do simple OS3.1 install and see if problems occur there (I do however have the 3.9 ROM). If they do, then check the hardware and try more maxtransfer settings to see results....

rkauer · 18 June 2009, 21:16

With a 3.9 ROM you will not boot into 3.1, setpatch 3.1 chokes in his own vomit and don't load Workbench.

Calgor · 19 June 2009, 06:57

My workbench 3.1 floppy loads up just fine. I think you left out workbench.library in your 3.9 ROM (mine is 1MB ROM so has room) which is the real problem which will result in no workbench.

Calgor · 20 June 2009, 20:35

Further testing reveals the problem happens regardless of FFS/SFS filesystem.

Also I have only been able to reproduce the errors while writing to the SD card. So far from multiple attempts when copying the file from the SD card to RAM or CF0 it has always maintained the same CRC.

Have left the Mask at 7FFFFFFE and MaxTransfer at 0x1FE00 for all tests now as large MaxTransfer of FFFFFF did not improve anything.

Time to try a hard disk (after backing it up in WinUAE) then if that works a different SD adapter and SD card. If hard disk does not work then time to mess with the SCSI chain.

thomas · 20 June 2009, 20:52

What kind of SCSI-IDE adapter do you use ? I remember other people having had similar problems with big IDE harddrives on the CSPPC which were solved by downgrading the Acard SCSI-IDE to an older firmware.

Calgor · 20 June 2009, 21:03

I am using Acard 7720U 50 pin SCSI to IDE older firmware 3.75. But also this IDE-SDHC adapter would possibly put in extra complications.

On my CSPPC successfully using Acard 7720UW 68 pin SCSI to IDE with 320GB IDE hard disk with no hard disk errors ever encountered.

thomas · 20 June 2009, 22:14

The discussion I found in a different forum says that version 3.88 causes read errors while 3.66 works fine. 3.75 is exactly in the middle so I cannot tell if it is good or bad.

Calgor · 21 June 2009, 07:07

Interesting on the Acard website they currently allow you to download 3.64 (still although it is old), 3.86, 3.89, 6.89 (if you manually type in URL you can also get what are probably for 7720U/7720UW 3.79, 3.80, 3.82, 3.85). Unfortunately I do not have a PC scsi adapter to update the firmware. I have a USB-SCSI but it could not find the Acard.

Where is this forum discussion? Were they getting write errors too or only read errors? What kind of read errors?

thomas · 21 June 2009, 09:31

http://www.a1k.org/forum/showthread.php?t=15630

It's German...

Calgor · 02 April 2010, 05:39

Thanks thomas, although that thread seems to only talk about the Acard 7720UW needing to be downgraded from firmware 3.88/6.88 to 3.64/3.66 to solve data errors.

Could not find mention with google translate of a problem specifically with the 7720U. If I eliminate all the other possibilities, then I will have to consider flashing 7720U with other firmware.

Have set aside some time so hopefully get to the bottom of this.

Calgor · 02 April 2010, 13:29

Well maybe I have it sorted, only time with more copying will tell. No errors when supplying termination power from the Acard adapter. As my external active terminator had the light on I thought that the Blizzard SCSI Kit was supplying the termination power.

Does the SCSI Kit actually provide any termination power? If not, I wonder how my external active scsi terminator had its indicator light lit up (and what the point of the light is)

18 June 2009, 13:08	#1
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Data corruption problems copying files I am having intermittent data problems while transferring files. Sometimes it only happens on large files, other times I am not sure if it also happens on medium size files. Setup: A1200 Blizzard IV 030/50 + SCSI Kit + SCSI-IDE + IDE-SDHC + SDHC 16GB (only 1 scsi device on chain with ID 0) OS3.9BB2 1MB ROM + scsi 43.45 1230scsi.device 8.5 MaxTransfer = 0x1FE00 TransferMask = 0x7FFFFFFE Active termination on Acard SCSI-IDE adapter using its jumper. SFS 1.276 / FFS OS3.9BB2 45.13 The item with the problem is the SDHC card when copying files to it (from PCMCIA slot CF card or from Ram Disk), and possibly also reading files from it. When using only CF0 and RAM there are no problems. More than half the time on large files there is a problem. The larger the file the much more likely there is to be a problem. Results are different each time the file is copied. I check the 80MB file using GetCRC from aminet. Here is an example of one file with errors. The file is the same size as original, but some bytes are zeroes, and others are incorrect. There is a definite pattern, probably related to MaxTransfer or something. I compiled the below list of hex file locations with differences with assistance of "fc /b" command in vista command prompt. f0200-f0400 (zeroed) f0401-fffff (wrong) 15d0200-15d0400 (zeroed) 15d0401-15dffff (wrong) 2ad0200-2ad0400 (zeroed) 2ad0401-2adffff (wrong) 3d20200-3d20400 (zeroed) 3d20401-3d2ffff (wrong) 5180200-5180400 (zeroed) 5180401-518ffff (wrong) The number of bytes zeroed in each instance is just about 512, and the number of incorrect bytes (including zeroed) is about 65536-512. For the last 3 error ranges, the gap between them is even the same (2ad0200-3d20200-5180200 19MB gaps). Is this indicative of a bad cable, bad termination, wrong maxtransfer or something else?

18 June 2009, 17:28	#7
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,354	Your SCSI->IDE adapter should handle all the max transfer issues. You could try a higher more SCSI-esque value. But it shouldn't make a difference. I'll research what the "Mask" field actually does (if anything). Last edited by alexh; 18 June 2009 at 17:35.

20 June 2009, 20:35	#13
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Further testing reveals the problem happens regardless of FFS/SFS filesystem. Also I have only been able to reproduce the errors while writing to the SD card. So far from multiple attempts when copying the file from the SD card to RAM or CF0 it has always maintained the same CRC. Have left the Mask at 7FFFFFFE and MaxTransfer at 0x1FE00 for all tests now as large MaxTransfer of FFFFFF did not improve anything. Time to try a hard disk (after backing it up in WinUAE) then if that works a different SD adapter and SD card. If hard disk does not work then time to mess with the SCSI chain. Last edited by Calgor; 20 June 2009 at 20:41.

21 June 2009, 07:07	#17
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Interesting on the Acard website they currently allow you to download 3.64 (still although it is old), 3.86, 3.89, 6.89 (if you manually type in URL you can also get what are probably for 7720U/7720UW 3.79, 3.80, 3.82, 3.85). Unfortunately I do not have a PC scsi adapter to update the firmware. I have a USB-SCSI but it could not find the Acard. Where is this forum discussion? Were they getting write errors too or only read errors? What kind of read errors? Last edited by Calgor; 21 June 2009 at 07:12.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Freezing when copying files over network	Firestone	support.Other	1	10 July 2013 08:06
Copying files	commodoresales	New to Emulation or Amiga scene	5	24 March 2012 21:57
Copying ADF files form PC to A600. Help!	entireweb	New to Emulation or Amiga scene	6	03 September 2011 21:36
Apollo 1260 problem copying small files	abraXXious	support.Hardware	15	14 July 2011 13:10
v26 CF problem: copying files causes a crash	emuola	project.ClassicWB	6	11 May 2011 20:28

18 June 2009, 13:56	#2
Loedown Precious & fragile things Join Date: Feb 2009 Location: Victoria, Australia Posts: 1,946	Greetings, I would ask how old the PCMCIA card is, as they use flash technology, which has a finite life, 1000 read / write cycles. I know from experience that these sorts of problems will be rather obscure, I really wish you well with this one. I might also suggest looking at the HDD ribbon cable to ensure it hasn't rubbed through and allowed some wires to be randomly grounded etc.

18 June 2009, 14:12	#3
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Hi Lowdown thanks, but not sure which card you are asking about. The problem is independent of the PCMCIA slot (and the card therein) It happens when copying from RAM to the SDHC card. If it is the SDHC card you are asking about, it is virtually brand new I got it a short while ago. The SCSI chain is about 30cm long from SCSI Kit to 25-50 pin adapter to Acard adapter which is the end of the chain. There is also an IDE cable from Acard adapter to IDE-SDHC adapter which is about 5cm long. Both are self-made cables. SCSI Kit -> 30cm 25pin cable -> 25-50pin adapter -> 5cm 50pin cable -> Acard SCSI-IDE Adapter (active termination) -> 5cm 40pin IDE cable -> IDE-SDHC adapter with 16GB SDHC card So yes, a problem with the chain is a possibility.

18 June 2009, 14:28	#4
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Very strange. I changed the Mask to 0x0FFFFFFC and MaxTransfer to 0xFE00 and now the computer is crashing and rebooting in the middle of copying files! But it was successful for the FFS partition but big problems in SFS partition. Stay tuned...

18 June 2009, 14:41	#5
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Well the computer will not even boot now unless I disable all the HD partitions in the boot menu. Back to the drawing board wipe the whole SD card and start again. Not the first time since the SFS 1.275 debacle and the FastATA MK-III bug debacles. Who know what the problem was this time. I will only use FFS until it is stable this time. If someone can please look at the first post and suggest what may be causing that pattern of errors in the files.

18 June 2009, 16:46	#6
Anemos 70X7 Join Date: Apr 2008 Location: Ἑλλάς Posts: 1,078	Similar problem here before change my PSU with bigger/Watt/amp. Test another PSU.

18 June 2009, 17:51	#8
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,518	if ((mask & address) == address) -> memory address can be used for data transfer. At least it is supposed to work like this 0x0FFFFFFC mask means Blizzard's fast ram can't be used (it is located at 0x68000000). Pointless mask in any case, usually mask is used to limit transfers to 24-bit fast ram only (for example A590/A2091 DMA is 24-bit only), 0x00fffffc or chip ram only which is 0x001ffffc. EDIT: with incompatible mask driver should either fall back to PIO or use separate DMA compatible buffer + CPU transfer (not sure if this is implemented in all drivers..)

18 June 2009, 17:56	#9
alexh Thalion Webshrine Join Date: Jan 2004 Location: Oxford Posts: 14,354	Interesting stuff.

18 June 2009, 18:08	#10
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Hmm.. I knew the Mask limited the area of memory which can be used (from those DosDriver mountlists), but did not add 1+1 to figure that value excludes the fastram on Blizzard. So that was not very useful but should not have been the cause for the computer to crash. Anyway, I have now reformatted the SD card in the PC so now the Amiga boots up with it - RDB or something must have been corrupted to make it worse than a non-formatted drive causing amiga not to be able to boot even when trying to boot off floppy. Next step is to do simple OS3.1 install and see if problems occur there (I do however have the 3.9 ROM). If they do, then check the hardware and try more maxtransfer settings to see results....

18 June 2009, 21:16	#11
rkauer I hate potatos and shirts Join Date: Oct 2007 Location: Sao Leopoldo / Brazil Age: 58 Posts: 3,482	With a 3.9 ROM you will not boot into 3.1, setpatch 3.1 chokes in his own vomit and don't load Workbench.

19 June 2009, 06:57	#12
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	My workbench 3.1 floppy loads up just fine. I think you left out workbench.library in your 3.9 ROM (mine is 1MB ROM so has room) which is the real problem which will result in no workbench.

20 June 2009, 20:52	#14
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 7,001	What kind of SCSI-IDE adapter do you use ? I remember other people having had similar problems with big IDE harddrives on the CSPPC which were solved by downgrading the Acard SCSI-IDE to an older firmware.

20 June 2009, 21:03	#15
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	I am using Acard 7720U 50 pin SCSI to IDE older firmware 3.75. But also this IDE-SDHC adapter would possibly put in extra complications. On my CSPPC successfully using Acard 7720UW 68 pin SCSI to IDE with 320GB IDE hard disk with no hard disk errors ever encountered.

20 June 2009, 22:14	#16
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 7,001	The discussion I found in a different forum says that version 3.88 causes read errors while 3.66 works fine. 3.75 is exactly in the middle so I cannot tell if it is good or bad.

21 June 2009, 09:31	#18
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 7,001	http://www.a1k.org/forum/showthread.php?t=15630 It's German...

02 April 2010, 05:39	#19
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Thanks thomas, although that thread seems to only talk about the Acard 7720UW needing to be downgraded from firmware 3.88/6.88 to 3.64/3.66 to solve data errors. Could not find mention with google translate of a problem specifically with the 7720U. If I eliminate all the other possibilities, then I will have to consider flashing 7720U with other firmware. Have set aside some time so hopefully get to the bottom of this.

02 April 2010, 13:29	#20
Calgor (Amigas && Amigos)++ Join Date: Sep 2005 Location: Anrea Posts: 999	Well maybe I have it sorted, only time with more copying will tell. No errors when supplying termination power from the Acard adapter. As my external active terminator had the light on I thought that the Blizzard SCSI Kit was supplying the termination power. Does the SCSI Kit actually provide any termination power? If not, I wonder how my external active scsi terminator had its indicator light lit up (and what the point of the light is)

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