Falcon SCSI write issues

[exxos]

If I have time tonight I'll try to chuck around some CDRom images or Tentacle's sound file between IDE and SCSI & see what happens.

If you do , don't use HDdriver >12.53 as it doesn't show the issue. Also make sure you have a 14MB STram card.

[stephen_usher]

[rying to copy a large file like 10MB fails.. But if I use a 4MB STram card, it works. Which suggests theres a maximum chunk size of maybe 3MB at a guess. HD 12.71 limits to 64KB chunks, so it also works.

Jookies program was for testing cosmosex , he had the exact same issue. I'm waiting for him to patch the program because it was not designed to run on anything else. He says he does not even use a driver. So I guess he just issues raw SCSI commands to the drive.

We may be able to tell more when I can run his program, but I think this is just not going to be resolvable. I cannot even say if it's a hardware or software issue but I would side with hardware currently. But it could may well be a inherent bug in the falcon's logic somewhere for all we know. I have literally zero idea what this problem could be.

OK, so there is probably a hardware design issue with the SCSI interface with regards to DMA where over some limit the DMA corrupts. This sort of thing is not uncommon even now and the hardware vendor just lists it as a hardware errata and driver developers work around it (by using smaller DMA transfers, for example). Maybe there's an off by one error in an address counter in the DMA chip? Who knows? The important thing is finding what that limit is and then all drivers/software updated to avoid ticking the hardware bug.

I can't remember if the Falcon uses an NCR 5380 SCSI chip or not.

[jwd]

I presume SCSI drive end is fully terminated etc.?

If i was a betting man i would say hardware fault somewhere.

Can you do the same copy on an ST with SD card reader > ICD link or similar > same SCSI drive.

[exxos]

OK, so there is probably a hardware design issue with the SCSI interface with regards to DMA where over some limit the DMA corrupts. This sort of thing is not uncommon even now and the hardware vendor just lists it as a hardware errata and driver developers work around it (by using smaller DMA transfers, for example). Maybe there's an off by one error in an address counter in the DMA chip? Who knows? The important thing is finding what that limit is and then all drivers/software updated to avoid ticking the hardware bug.

I can't remember if the Falcon uses an NCR 5380 SCSI chip or not.

Yeah 5380 stamped on mine.

Until more tests can be done, I can only guess that the limit is probably around 6MB. just based on file sizes I've copied previously.

Maybe it is not possible for SCSI to hog the bus for that amount of time and something else trips up

[Badwolf]

If you do , don't use HDdriver >12.53 as it doesn't show the issue. Also make sure you have a 14MB STram card.

Oh right. Yeah. I could use EmuTOS for the driver, or load v11.14 from floppy, but I do only have a 4MB card in this machine.

BW

[exxos]

I presume SCSI drive end is fully terminated etc.?
[

Tried with and without.

If i was a betting man i would say hardware fault somewhere.

Can you do the same copy on an ST with SD card reader > ICD link or similar > same SCSI drive.

I don't have any SCSI adapters anymore for the ST

[exxos]

Oh right. Yeah. I could use EmuTOS for the driver, or load v11.14 from floppy, but I do only have a 4MB card in this machine.

The problem doesn't show up with a 4MB card. EMUTOS seemed to chug along regardless and trashed the partition. So I don't think its a good idea to try it at this point. At least TOS404 "dies" and doesn't corrupt the partition.

[stephen_usher]

Yeah 5380 stamped on mine.

Until more tests can be done, I can only guess that the limit is probably around 6MB. just based on file sizes I've copied previously.

Maybe it is not possible for SCSI to hog the bus for that amount of time and something else trips up

Well, the TT using the same chip doesn't have the problem, nor do Sun workstations.

The size of the file shouldn't matter as the data across the SCSI bus are packets of data far smaller than the file itself.

Copying a file would be a series of reads and writes. Reading into a buffer and then writing that buffer out. It will also be doing a seek and a read/write to the FAT at some point. If there's corruption only when you have more RAM (and hence probably a larger slave buffer) then it may be to do with the DMA above a certain RAM address being broken, or when straddling a certain address boundary.

What is corrupting? The file or the file system or both?

If it's a filesystem corruption then that would be a seek and a small write, probably a single 512 byte block.

Of course, if it's hitting a DMA hardware bug then it could well be out of sync with addressing until it's reset.

[exxos]

@stephen_usher see my first posts..
viewtopic.php?p=134297#p134297

[stephen_usher]

Looks like it's not sending the correct data then, which suggests to me an addressing error inside the DMA chip. i.e. some sort of error where the address being asked for over the bus is wrong. I would imagine once it's got into this state then it stays "broken" until a reset. Probably sending garbage down the SCSI bus and writing what it receives to the wrong memory address.