dhedberg wrote:I activated verify on write for the driver without seeing any improvements whatsoever.
Ow drat, that should have helped.
dhedberg wrote:How does the RAW mode work? How is the data buffered in the RPi? It appears to me that there is a cache involved (in the RPi) in which the data is actually correct and which is accessed when verify is activated, but when the data is later actually written to the SD-card it is corrupted or the cache is corrupted. Does this make sense? It's hard to explain otherwise why verify does not detect the corruption.
The RAW mode is related to USB drives - acting as a bunch of sectors to ST, so HDDRIVER (or any other RAW disk driver) can handle it at sector level. It's used when you plug USB drive to USB port, the sectors of that drive are accessed and forwarded to ST, or written from ST to it. There might be some buffering done there (in linux kernel), so after writing data to RAW USB drive (or even better - to USB drive in general, even in translated mode), you should use CE_MOUNT.PRG to unmount that drive before you remove it from USB drive, that should flush all the caches. It shouldn't be related to SD card as you mention the SD card there...
Btw., I got one promising fix for the SCSI transfer issues - that problematic device which failed the stress test a lot now seems to be working fine. I need to do more stress testing, data validity testing, and if it's fine, then I need to test it on the other device, which didn't suffer from this problem (or it suffered only very occasionally, so I didn't notice it). If the same passes on the better device, then I will consider this as a good fix and there will be an update of the Xilinx firmware for SCSI tomorrow or the day after that.
If it will fail (for some magical reasons), I have a different fix and code in an alternative git branch, that would require one week or so of finishing, and it would mean a change to all the devices (even ACSI ones), so I hope that the SCSI fix will be just fine because this is much more work