Synchronous transfer rate at 5MB/s on PS/2 Model 77 fails (Zulu v1.1)

[jtgans]

Model: ZuluSCSI 1.1
SD Card: SanDisk Ultra 80MB/s SDHC I class 10 16GB
ConnectIon: stock IBM SCSI cable for the Model 77, approx 3' long, connected to Bermuda motherboard SCSI adapter on the first connector, approx 6" away from the motherboard.

Been troubleshooting this one for a while now -- been stymied by Model 77 weirdness with regard to how it boots (IPL from HD). Near as I can tell, either the ZuluSCSI isn't using the timing the PS/2 wants, or negotiation is going south or something equivalent to both.

At the moment, my zuluscsi.ini contains the following:

[SCSI]
DisableStatusLED = 0
EnableParity = 1
EnableSCSI2 = 1
MaxSyncSpeed = 10

Vendor = "IBM"
Product = "WDS-3200"
Version = "1.0"
Serial = "0123456789ABCDEF"
Type = 0
TypeModifier = 0
SectorsPerTrack = 63
HeadsPerCylinder = 255
RightAlignStrings = 0
PrefetchBytes = 8192

This results in the attached log file, and a failed IPL (early early boot -- these stupid machines have their early BIOS stored to disk). On the other hand, if I set MaxSyncSpeed to 0, magically everything just works.

This machine should be capable of 5MB/s synchronous transfers using the SCSI-2 command set. According to IBM themselves (and copied off ardent-tool.com):

• Supports SCSI Common Command Set Version 4.B (SCSI-2 Compliant)
• Attachment of up to 7 SCSI physical devices (internal and external)
• Allows multiple SCSI initiators for device sharing
• SCSI Data Transfer Rate - up to 5.0 MB/sec
• Supports Synchronous and Asynchronous SCSI Data Transfers
• Supports disconnect/reconnect of SCSI targets
• Automatic external SCSI bus detection (disables internal planar terminator automatically)
• Slew rate controlled SCSI drivers and filtered SCSI receivers for high data integrity.

Thoughts on what I might try, or if you guys see anything useful in those logs? I tried to dig through, but it looked like normal read requests (Read6 followed by a Read10 to fetch the IPL signature, both look correct from what I can tell in terms of the return data and what's in the disk image).

FWIW, this adapter is apparently known as the IBM "Spock" SCSI card.

zululog.txt

[jtgans]

Interesting update: I just had it fail IPL with MaxSyncSpeed set to 0 and EnableSCSI2 set to 1. Setting EnableSCSI2 to 0 allowed it to boot again. So some kind of instability here.

For reference, attached is a successful IPL / MS-DOS boot.

zululog.txt

[jtgans]

Also, FWIW, I tried every option for the PHYs, only one that seems to work is GREENPAK_DMA. GreenPAK PIO runs afoul of watchdog timeouts, and the others just fail to boot in exactly the same way as before when MaxSyncSpeed is anything other than 0.

I've also tried setting the selection delay to 10, then 5, then 3, and finally 2, with much the same results.

[PetteriAimonen]

In comparing the two logs, it appears that in normal boot after the Read 256x512 starting at 1105565 a new boot phase should begin with bus scanning, but it doesn't seem to be happening. Is there any error messages or other status messages from the computer?

The reasonable explanation would be some kind of transfer corruption in the IPL data, which then causes the computer to crash. But normally that would be detected as parity error by the computer.

The host requests 200 ns period / 7 offset syncronous mode, the actual device-to-host timing used by ZuluSCSI v1.1 for these parameters is 260 ns / 7 offset so there should be even extra margin in the timing.

I don't know what might be going wrong with the transfer.
You could try the latest development build here: https://github.com/ZuluSCSI/ZuluSCSI-firmware/releases/tag/latest
It has some improvements in logging in stuck situations, so maybe something more will be revealed.
Also wait at least 30 seconds after it gets stuck to give time for watchdog timer to expire and log info if it will.

[aperezbios]

@jtgans does it behave any differently if you disable synchronous transfers entirely, with "MaxSyncSpeed = 0"? If you haven't tested that yet, it would be a good data point to have. Thanks for reporting this.

[jtgans]

In comparing the two logs, it appears that in normal boot after the Read 256x512 starting at 1105565 a new boot phase should begin with bus scanning, but it doesn't seem to be happening. Is there any error messages or other status messages from the computer?

IBM PS/2 Model 77s actually cache the SCSI bus identifier for the boot disk and other devices in the onboard EEPROM (kinda like what they do with MCA devices), so what you might be seeing is normal during a boot for this machine. There aren't any errors being reported to me during a normal boot, and typically IBM PS/2s are pretty pedantic about errors.

The reasonable explanation would be some kind of transfer corruption in the IPL data, which then causes the computer to crash. But normally that would be detected as parity error by the computer.

Yeah, I think it's something equivalent to this happening. During a failed IPL boot, the firmware will retry several times, and only once it's failed all of them, report failure.

The host requests 200 ns period / 7 offset syncronous mode, the actual device-to-host timing used by ZuluSCSI v1.1 for these parameters is 260 ns / 7 offset so there should be even extra margin in the timing.

Makes me wonder if perhaps that extra margin is causing issues? During the IPL, I don't think we're talking to a sane SCSI controller, TBH -- might just be "enough" of a firmware to pull in the first-stage IPL to bring everything else up.

If I can, I'll try hooking up the SCSI bus to my network analyzer and get a dump of what's going on.

I don't know what might be going wrong with the transfer. You could try the latest development build here: https://github.com/ZuluSCSI/ZuluSCSI-firmware/releases/tag/latest It has some improvements in logging in stuck situations, so maybe something more will be revealed. Also wait at least 30 seconds after it gets stuck to give time for watchdog timer to expire and log info if it will.

Will do!

[jtgans]

@jtgans does it behave any differently if you disable synchronous transfers entirely, with "MaxSyncSpeed = 0"? If you haven't tested that yet, it would be a good data point to have. Thanks for reporting this.

Ah, I thought I mentioned this in the original report: setting MaxSyncSpeed to 0 gets the machine to boot fine. It's only when it negotiates 5MB/s or SCSI-2 that it won't IPL anymore.

[aperezbios]

Ah thanks, @jtgans, you definitely did ("if I set MaxSyncSpeed to 0, magically everything just works.") and I just overlooked it. This is quite a strange issue, so it will likely take some time for us to figure it out fully, but in the meantime, at least you can set MaxSyncSpeed to zero as a way to reliably work around the issue, for now.

[aperezbios]

@jtgans can you try the latest firmware release and let us know if you're still experiencing this issue?

[jtgans]

Will do! I'll have to go re-hook up my 77, but will definitely give it a shot tomorrow.

[aperezbios]

@jtgans ping :)

[aperezbios]

No reponse from reporting party. Closing.