DaynaPort Wifi compatibility for NETBSD

[speakers-k64]

This change applies the send delay to MacOS only and uses a minimum packet size of 128 bytes.

Tested with a Macintosh SE/30 running MacOS 7.6.1 and then booting either NetBSD 3.1.1 or NetBSD 9.3 built with dse driver.

Refer also to recent similar changes made in the develop branch of the SCSI2Pi project.

[erichelgeson]

uweseimet/scsi2pi@0aa9243

[jcs]

What is the performance difference on NetBSD when the delay is left in?

[speakers-k64]

NetBSD doesn't work at all with the delay. It's not a question of performance.

For PiSCSI and SCSI2Pi, packets are garbled and, in particular, packet sizes are corrupted. For BlueSCSI-v2, I think I found that NetBSD locked up!

[jcs]

So the NetBSD driver doesn't work with a real DaynaPort that has a delay?

[speakers-k64]

I don't know about the real Daynaport gear. I suspect it must not delay when talking to NetBSD.

[uweseimet]

@jcs I just noticed this ticket, and I discussed similar issues with @speakers-k64 in uweseimet/scsi2pi#5.

Looks as if you have stumbled upon the same question I am still wondering about: It is extremely unlikely that the real DaynaPort adapts its timing to the operating system used. So what's really happening here? What is the DaynaPort doing that its firmware works with different drivers, and why do the emulations need work-arounds for all drivers except for the Atari drivers?

This is a summary of what has already been tested with different platforms:

• With slow Macs the DaynaPort driver only works with a delay. Fast Macs also work without a delay.
• The NetBSD drivers only work without a delay and appear to be very sensitive to small timing changes, even when the timings are SCSI-compliant. This indicates a general issue with the SCSI REQ/ACK handshake on the driver's side.
• The Atari drivers (both have the same codebase) work with and without a delay, with both the Atari's ACSI and SCSI bus. I know that these drivers have also been tested with a real DaynaPort device.

The Atari uses a DMA chip for the handshake, i.e. the hardware controls the REQ/ACK signals. The fact that in this case delays do not matter indicates that a proper handshake copes with any delay as long as this delay is covered by the SCSI specs. The timing should not matter anyway, because the REQ/ACK signals control the handshake.

Does the Mac also have SCSI/DMA hardware, or does the CPU do the timing/handshake? Or does this depend on the Mac model? If there was SCSI/DMA hardware one would expect MacOS and NetBSD not to differ in behavior, provided they both use this hardware.

[jcs]

If the NetBSD driver doesn't work with real DaynaPort hardware that implements a delay, then in my opinion that driver should be fixed. I think changing 3 different hardware implementations to work around flaws in one open source software driver that doesn't even support the real hardware it's written for is the wrong approach. And I say that as an OpenBSD kernel developer for 20+ years.

[uweseimet]

@jcs Do you definitely know that the the NetBSD drivers do not work with real DaynaPort hardware?
@speakers-k64 Correct me if I am wrong, or if I misunderstood you, but my impression was that you knew that the NetBSD drivers were compatible with a real DaynaPort. The main reason to change SCSI2Pi was the assumption that these drivers were compatible with the real hardware, even though in the SCSI2Pi ticket I pointed out my doubts about the quality of these drivers more than once ;-).

[jcs]

I don't, I haven't done any testing with NetBSD. I'm just going off of what was posted earlier that said "For BlueSCSI-v2, I think I found that NetBSD locked up".

If NetBSD does work with a real DaynaPort then there are implementation differences between the real DaynaPort and the emulation in BlueSCSI that I would like to fix, rather than trying to guess whether NetBSD is probing and disabling the delay.

[uweseimet]

@jcs I agree. The emulation should behave like the original hardware as far as possible. If there are several drivers that are known to work fine with the original hardware, then if the emulation does not also work something is wrong with the emulation. If there are drivers where it is unknown whether they work with the real hardware they are not useful as a reference.

[jcs]

Also, if the NetBSD driver (or any other driver) wants to disable the delay for performance, I think BlueSCSI should implement a specific vendor command (like all of the Wi-Fi ones) that does it, rather than guessing based on the probe. That way it's explicit and an opt-in mechanism that the driver has to check for and perform, rather than the hardware doing it by default for anything that doesn't probe the same way as Mac OS.

[speakers-k64]

@speakers-k64 Correct me if I am wrong, or if I misunderstood you, but my impression was that you knew that the NetBSD drivers were compatible with a real DaynaPort.

I don't know this from personal experience with a real Daynaport box, no. But the NetBSD driver was accepted after review (about a year ago) and I can only presume that it was tested with the original hardware.

@jcs The send delay seems to be specific for the Daynaport driver on MacOS. The original hardware ran firmware which may have enabled this send delay after receiving the non-standard 37-byte INQUIRY from the MacOS driver. But I'm guessing here.

[speakers-k64]

I'm attempting to contact the submitter of the NetBSD dse driver to get information on what configurations have been tested.

[speakers-k64]

I'm now in contact with the submitter of dse who said:

The dse driver was updated by me and tested on a Powerbook 160 with PiSCSI
with RPI3 hardware.

I've just got in touch with a fellow developer who has original Dayna hardware
to confirm whether the dse(4) driver works for him also. He did write to a ML
about it some time ago, but I'd thought I'd ask again to be certain.

I'll give you more information from him when he gets back to me.

He also pointed out an issue with some Mac platforms (including SE/30) which requires an additional kernel patch. I'm now investigating this. @uweseimet your suspicions may indeed be correct.

[speakers-k64]

I've yet to determine how much testing has been done with real Daynaport hardware, but PiSCSI emulation seems to be used predominantly.

There are known issues with NetBSD on early Macs using the NCR 5389 SBC chip .. this includes the SE/30. Specifically, this involves pseudo DMA mode - see http://mail-index.netbsd.org/tech-kern/2022/12/22/msg028597.html Patching the kernel to avoid these issues enables me to interface my SE/30 successfully with BlueSCSI-v2, PiSCSI , and SCSI2Pi running release firmware (i.e. without my patch).

So it seems that the Daynaport send delay triggers failure of pseudo DMA receives on my SE/30 although I don't know the exact failure mechanism. This also occurs on my IIci which uses the same SCSI chip. However, my Quadra700 has a different SCSI controller implementation and it doesn't suffer this problem.

So I'll withdraw this pull request since:

• the behavior of BlueSCSI/PiSCSI/SCSI2Pi should remain consistent with real Daynaport hardware, and
• I can resolve this issue by patching the NETBSD kernel myself.

[uweseimet]

@speakers-k64 Thank you for investigating this. Correct me if I am wrong, but this means that I can remove the work-around for NetBSD also from SCSi2Pi, can't I? As mentioned in uweseimet/scsi2pi#5 this work-around might sooner or later cause problems when further developing SCSI2Pi.

[speakers-k64]

@uweseimet Indeed. I was about to suggest its removal from SCSI2Pi.

The workaround does seem ill-advised currently although inhibiting the send delay may provide an optional (though minor) performance enhancement for NetBSD in the future.

[uweseimet]

@speakers-k64 OK. I will remove if with the next release, i.e. SCSI2Pi 1.2.

I doubt that removing the delay will have a relevant impact on performance. As far as I can tell the DaynaPort drivers poll for new network packets with a very high rate (more than once per second). This is where I expect considerable impacts on performance, not just on the DaynaPort emulation, but on the device emulation in general.

[speakers-k64]

I measure a slight performance boost (~10% faster input) on SE/30 presumably because unpatched NetBSD is able to use PDMA.

I would hope that emulation will be developed to deliver multiple network input packets per SCSI send - of which the original Daynaport hardware was capable and the NetBSD driver expects.

[uweseimet]

@speakers-k64 I am afraid at least as far as I am concerned I do not plan to add more functionality to this driver. The SCSI commands supported by the DaynaPort are only porly documented (I guess somebody did quite a lot of tries and errors in the past), and testing is a pain. In addition, as long as drivers pull data several times per second the overal emulation performance will always suffer.
And we have learned that whatever NetBSD does/expects does not mean that much ;-).

[uweseimet]

@speakers-k64 Is my assumption correct that you triggered PiSCSI/piscsi#1098? If it is, I recommend that you close this ticket with a comment why it has become obsolete.