SD Aide (for SCSI Emulator power up lock up issues)

[jmacz]

Problem

Some users (me and a few others) have experienced lock ups in our PowerBooks when SCSI emulation devices (ZuluSCSI, BlueSCSI, etc) are spun down for power conservation and then subsequently spun back up. SCSI2SD seems to not have this issue but it seems some folks using the other two major brands (ZuluSCSI and BlueSCSI) have had issues. For those of us having issues, it has occurred in System 7.1 through System 7.5.5.

Why does it happen? (Working Theory)

It seems after power is restored to these SCSI emulators, the system software will quickly (within 500ms) issue the IO request that caused the SCSI emulator to be spun back up (ie. have its power restored). If the SCSI emulator device isn't ready when this IO request comes in, you get into this hung state because the SCSI emulator misses the request and sits around waiting for a request, whereas the system software issued the request and sits around waiting for a response. This lockup lasts for 180 seconds after which the system finally unfreezes.

Why are some devices ok?

I believe it's all in the timing. If the device can become operational before the IO request comes in, you're all good. Some devices (and/or their firmware version) either get ready quickly or get into a state where it can read and hold the IO request until the device is fully ready to go (ie. don't miss the request). I have not been able to reproduce the issue with a SCSI2SD device. It's possible that's because SCSI2SD uses the SD card as a raw disk whereas ZuluSCSI and BlueSCSI have an extra layer (filesystem) from which it exposes multiple disks. Or it could be those other two devices offer more features and it takes more time to get ready? I have heard newer BlueSCSI's might be ok? If you aren't having these issues, awesome! But if you are, continue reading.

Solution



SD Aide is a system extension / control panel which intercepts the HD spin up function in the system software and after spin up, adds a configurable delay to allow the device to finish booting before the IO request is sent. This ensures the SCSI emulator device does not miss the request so that your PowerBook isn't locked up for 3 minutes every time the disk is spun down. You can of course just disable spin down but this option doesn't exist in System 7.1 through 7.1.1, and that wouldn't help with sleep mode.

Just drop SD Aide into your control panel folder, double click it and configure the delay you want, and then reboot. The ZuluSCSI devices I have used (stock configuration) seem to like 2-3 seconds of delay. The BlueSCSI device that @3lectr1cPPC has wanted a 4 second delay.

Requirements

SD Aide only runs on System 7 or greater, only on 68K, and only on Macintoshes that have a power manager implementation (ie. PowerBooks).

Tested

SD Aide has been tested on System 7.1, 7.1.1, 7.1.2, and 7.5.5. It has been tested on a PowerBook 540c, PowerBook 170, and a PowerBook 160. It has been tested with a ZuluSCSI 1.1 Laptop Edition, a BlueSCSI device, and a SCSI2SD (although it didn't need it).

Download

Version 0.5.0 is attached in binhex stuffed format. There's an included README file.

Issues

If you have any issues, feel free to leave me a note here in this thread. Given I am not a company nor am I charging for this, I have to state that this is a "use at your own risk" type of thing and responses to questions could be delayed as I'm not providing 24/7 support here

 

[3lectr1cPPC]

I cannot thank you enough for creating this tool, it's going to help out so many people. I'm glad I could help with testing!

To add a couple details - The system I was testing on was my PowerBook 170 which has a BlueSCSI V2 in it. My PowerBook 180c has the older V1-based "F4Lite" that Androda used to sell, and it does not have the same problem. This makes sense when you think about it because the V1 and V2 BlueSCSIs have nothing in common aside from how they handle disc images - the V2 uses nearly the same codebase that the ZuluSCSI does, which would explain why those are the two devices that have this bug. Hopefully with help from your tool and your theory on the culprit behind the bug, one or both of the teams can work to see if they can fix this issue from the root cause. The F4Lite BlueSCSI in my 180c comes back online basically instantly, so it must be possible.

 

[3lectr1cPPC]

I'm also going to link to this thread on TinkerDifferent - the BlueSCSI devs are active there.

 

[jmacz]

I could be wrong, but my guess is it should be possible to get these devices up very quickly just to start sniffing for IO requests while in parallel still continue bringing up all the other functionality in the device. That way the request isn't missed. I didn't see any feature like this in the products but if I missed it and there's another way to ensure these devices don't miss a request, that would eliminate the need for SD Aide.

 

[SuperSVGA]

Well the issue is likely the RP2040 and the design of the boards.

On a normal SCSI device, when power is applied the terminators receive power and the SCSI bus is pulled up. No signaling comes from the SCSI device because SCSI device isn't ready yet.

On the RP2040 it powers up with all pins in a pull-down state, asserting the SCSI control lines. The RP2040 has asserted the C/D* and I/O* lines so the computer is now waiting for REQ* to be asserted by the RP2040 to start the data transfer.
REQ* is never asserted since the RP2040 was just powering up, it never intended to transfer data. The wait for REQ* eventually times out and returns an error.

 

[cheesestraws]

Are you going to release the soure code to this? Your choice, of course, but I'd love to read it.

 

[croissantking]

Thank you for your hard work and for sharing this with the community. You’ve made the 68k PowerBook restoration experience better for everybody. It’s reassuring to know that If I ever have problems of this kind that there’s now a solution.

 

[saybur]

Awesome, thanks for writing this! I'll echo @cheesestraws comment, if you end up deciding to release the source I'd love to take a look, this is doing some cool work.

 

[3lectr1cPPC]

Androda said on the TinkerDifferent discord that BlueSCSI hardware revisions starting with 2023-09 have this issue fixed. I guess it’s a hardware fault then and not something that can be fixed with firmware. Great to hear it’s fixed!

 

[croissantking]

Androda said on the TinkerDifferent discord that BlueSCSI hardware revisions starting with 2023-09 have this issue fixed. I guess it’s a hardware fault then and not something that can be fixed with firmware. Great to hear it’s fixed!

Ah, my BlueSCSI V2s are labelled 2023.10a. I ordered them in Jan. That’s why I don’t see the issue.

 

[jmacz]

Well the issue is likely the RP2040 and the design of the boards.

On a normal SCSI device, when power is applied the terminators receive power and the SCSI bus is pulled up. No signaling comes from the SCSI device because SCSI device isn't ready yet.

On the RP2040 it powers up with all pins in a pull-down state, asserting the SCSI control lines. The RP2040 has asserted the C/D* and I/O* lines so the computer is now waiting for REQ* to be asserted by the RP2040 to start the data transfer.
REQ* is never asserted since the RP2040 was just powering up, it never intended to transfer data. The wait for REQ* eventually times out and returns an error.

Good to know!

Note my issue was specifically with the ZuluSCSI 1.1 Laptop version which was pre-RP2040.

Androda said on the TinkerDifferent discord that BlueSCSI hardware revisions starting with 2023-09 have this issue fixed. I guess it’s a hardware fault then and not something that can be fixed with firmware. Great to hear it’s fixed!

Oh cool! Glad to hear it's resolved on the newer versions.

 

[jmacz]

Are you going to release the soure code to this? Your choice, of course, but I'd love to read it.

Awesome, thanks for writing this! I'll echo @cheesestraws comment, if you end up deciding to release the source I'd love to take a look, this is doing some cool work.

Yeah, I can get around to releasing it, well at least the INIT part. The control panel part is boring and put together quickly so a little ugly.

 

[jmacz]

The source code for the INIT portion is here:

GitHub - jcdevzero/sd-aide

Contribute to jcdevzero/sd-aide development by creating an account on GitHub.

github.com

 

[saybur]

The source code for the INIT portion is here

This is great, thank you!

 

[cheesestraws]

Thankyou very much! I was very curious about what your patch was patching. Now all is clear.

 

[jmacz]

No prob, and yeah, very basic. Nothing crazy.