Fastlane Z3 w/BlueSCSI v2 - file system becomes borked

[samaron]

Greetings!

Have an Amiga 4000 that I have put together, but seem to have some trouble now with getting the storage solution to be reliable. In my case it is a Fastlane Z3 v2.2 card with a BlueSCSI v2 connected.

The symptoms are that when using the computer, it can suddenly freeze or reboot on its own. When it attempts to boot into Workbench again I am greeted with either file system error messages, AmigaDOS screen telling me an error with the startup-sequence, or it does boot into Workbench. On the latter, I find that files are missing when opening drawers. The filesystem errors are something like "ALERT: Wrong dirblock id 00000000 block 460270" from the PFS-III error requester. Running PFS Doctor afterwards results in a lot of errors found.

The Fastlane card has the latest ROM (v8.5), the motherboard has a Super Buster rev. 11. Both the controller and the drive has been terminated. When the card came into my possession, the resistors where missing and have been replaced with Mouser PN 652-4608X104221331LF. It has 64MB RAM installed, but I reconfigured it to be disabled as my accelerator card has 256MB. The BlueSCSI has the latest firmware installed. Mask is set as 0xFFFFFFFF and MaxTransfer is the default 0xFFFFFF.

I've tried creating new hard drive images, changed the RDB flag to put the drive into synchronous mode, added z3dmacontrol to startup-sequence (after SetPatch). Tried the mask set to 0xFFFFFFFC as well. None of this have helped so far.

I'm a bit lost on why it appears to have data integrity problems at this point. Booting from floppy the computer runs stable. It also ran stable on IDE in the past when I borrowed a drive to test with. Does anyone have some suggestions on what else to try? Perhaps the BlueSCSI needs to be configured in a very specific way? Or maybe some quirk with the Fastlane I'm not aware of?

[samaron]

Looked a bit more at the issue today.

Reading in the Fastlane Z3 manual, I noticed a paragraph describing that A3640 cards need either an 74FCT240 or 74FCT244 on the motherboard (U103) depending on the card revision. The previous accelerator card I were using was an A3640 rev. 3.0 that had been upgraded to a rev. 3.2 by replacing U209 and U204. The manual states that U103 on the motherboard has to be a 74FCT244 if it is a rev. 3.1 A3640. I assume the same is applicable for rev. 3.2 cards as well. I verified my motherboard has this part. Although now I am using an accelerator called TF4060. If this information is still applicable I'm not sure.

Wanted to try an IDE drive to rule out that it is the system itself that is unstable. It is perfectly stable when booting from floppy. However, with this new accelerator card I found that if I connect anything to the onboard IDE, the computer does not boot. The accelecator card has a 44-pin connector, to which I lack appropriate equipment for. I have to order some connectors and make an adapter cable.
The same applies to SCSI. Wanted to try a real hard drive, but the ones I have are 68-pin drives and lack an adapter to fit the 50-pin IDC cable.

Wanted to try a program called DirDiff to compare files. Have a floppy disk with that and other tools on it. Tried to make a duplicate drawer with many files, but the drive/computer would crash every time. Got the PFS-III error requester messages as mentioned in the first post. The DirDiff experiment was a failure.

I thought that perhaps my hard drive image is compromised in some way. Ran PFS Doctor in WinUAE and got no errors. Having the image copied over to the SD card and booting from floppy to run PFS Doctor on actual hardware, I am eventually greeted with errors. It does appear to be random when it detects errors, and the drive becomes corrupted. This is with the check function running, not repair.

Reading some more on the BlueSCSI, I found that there is an additional debug parameter that can be enabled in the bluescsi.ini file. Attatched are a couple of log files that are compressed in zip-format. Log.txt is from when I were just using Workbench. The computer froze and rebooted after running and exiting a couple of applications. Log2.txt is from when I booted from floppy and attempted to copy a drawer. Were greeted with PFS-III error requesters after a few minutes.
Haven't had a good look at these yet, but nothing appear to be out of the ordinary when I quickly scrolled through. Might still be some errors hidden inbetween all the SCSI bus messages.

[grelbfarlk]

Usually I would ask "Are you sure it's properly terminated?"

How well have you tested it? When it's booted up have you copied some gigabytes of stuff between drives with no problems?

However after getting everything set up correctly as far as you know, just running some stuff and eventually it just seems to eat the filesystem and running PFSDoctor fixes that with a whole lot of missing directories, which you restore from backup with WinUAE, it runs fine for a while. You can copy many gigabytes between drives, but then you start running stuff it eats itself?

Yeah that happens to me too.

[samaron]

One thing that did strike me regarding the termination is that the BlueSCSI V2 has active termination. Found this GitHub issue that says all V2 designs are active. The Fastlane Z3 is passive termination. Perhaps it would work better with an active terminator installed? Ordered one now in order to test.

Otherwise there's only the Fastlane and the BlueSCSI in the SCSI chain. Fastlane has the resistors installed, and BlueSCSI has the termination jumper closed (on). I am not using any external devices that would necessitates the removal of the Fastlane termination.

Tried to copy larger amounts of files on actual hardware, but have been unsuccesful every time. It borks itself. No problem in WinUAE.

[nogginthenog]

With a Mask of 0xFFFFFFFF it means the controller can use DMA to access all RAM. Are you sure this is correct? MaxTransfer shouldn't matter.

I use 0xFFFFFFFF on my CyberStorm MKII with CyberSCSI with BlueSCSI v2.

Did you try physically removing the 64MB RAM?

[samaron]

The accelerator card is the only thing providing RAM to the system now. As far as I understand this is the fastest RAM and the most beneficial to use. Removal of any other RAM is preferred, if possible. I suppose setting the mask to access all RAM is proper in this case?

The RAM on the Fastlane isn't physically removed, but it is disabled according to the manual. Setting 0: Switches the Fast-RAM off, or is set if no memory is configured on the Fastlane Z3. None of the utilities detect the 64MB it used to provide to the system. I could physically remove the RAM, but would prefer not to. The sockets feel very brittle.

I noticed now the compatibility page on the BlueSCSI wiki recommends 0xFFFFFFFE for a CyberStorm MKII. Since the cards are from the same company, I would assume the controllers are the same or very similar. Could try this mask too.

EDIT:
Had a better look at the logs and found a couple of concerns.

The first log ended with a "scsi_accel_rp2040_finishRead timeout" message. The BlueSCSI wiki says the following for this message: "This indicates that your SD card may be too old or slow to keep up with the SCSI bus of your system. Try a newer or faster speed SD card." It also suggests that the card might be faulty.

The second log have the following in multiple places:
SDIO card reports write CRC error, status 0xAC7FFFFF
SdioCard::writeSectors(0x0577526F,...,55) failed: 7
SD card write failed: 0x00
Again, the wiki page says "This usually means the SD card is faulty."

For all cases, the wiki recommends using the SD Memory Card Formatter tool provided by the SD Association. Eventhough the cards show signs that suggest they're faulty, a proper format could solve it. An option called "Overwrite format" has to be selected as well.

Digging deeper, I found another wiki page with SD card recommendations. Here it says to avoid all SanDisk cards, which is what I happen to have. Have bought a Samsung Pro Endurance card that I were planning to try, and happy to see it is on the recommended list. Still want to try the formatting tool, as I doubt there's anything wrong with my card. Bought it this summer after all. Why SanDisk isn't recommended is unclear.

[jlin_au]

1) You have not stated which versions of Kickstart and AmigaOS you are using on your Amiga 4000.
2) the 64Mb of RAM on the Fastlane is most likely used to either buffer the I/O to the physical storage device or to cache data that was previously "written to"/"read from" the physical storage device. In other words, by removing the 64MB, you're probably creating an extra bottleneck that will restrict the I/O bandwidth of any storage device connected to the Fastlane.
3) MaxTransfer controls the max number of Blocks that can be "read from"/"written to" via the AmigaOS level storage device in a single command and has been known to cause data or file system corruption issues on the physical storage device if set incorrectly especially under an OS3.1 or earlier version scsi.device . See https://eab.abime.net/showthread.php?t=96887 and https://eab.abime.net/showthread.php?t=117468.
Notes - maxtransfer issues do not appear under WINAUE because the I/Os go thru the Windows OS drivers.