Subject: Re: SBIC
To: Ignatios Souvatzis <firstname.lastname@example.org>
From: Berndt Josef Wulf <email@example.com>
Date: 11/04/1995 10:34:05
Ignatios Souvatzis writes:
> Date: Thu, 2 Nov 95 22:45:53 CST
> From: firstname.lastname@example.org (Bruce Albrecht)
> Sender: owner-amiga-dev@NetBSD.ORG
> Precedence: list
> X-Loop: amiga-dev@NetBSD.ORG
> Frank Dana wrote:
> The GENERIC system is supposed to "work on as many systems as possible"
> (says so right in the kernel config file). Well, async works on every sys-
> tem sync works on, plus a hell of a lot more. Do we need a better argument
> for defaulting to async?
> It would be great if sync worked. But it doesn't, and I don't think there's
> time left to iron out all of the problems.
> I cannot stress too much that I don't want the SBIC driver to go back
> to the original NetBSD-1.0 version. However, I think it's
> inappropriate for the default behaviour to be to turn on sync mode for
> all devices, since there are clearly too many devices that lock up
> when this happens. I don't know if the ultimate solution is to
> determine this at boot time, or to select it by controller/device when
> building a kernel. If neither of these options is likely to be
> implemented before the upcoming code freeze, then I think the only
> solution is to disable sync mode, and let knowledgeable users rebuild
> their kernel to turn it on (just the opposite of what I had to do).
> There is just one problem.
> If s.b. operates his Amiga 3000 with sync scsi under AmigaOS, and
> tries to boot an async netbsd kernel, it will freeze ALWAYS:
> a) the hardware can't reset the SCSI bus (with the exception of the
> CPU RESET instruction, which we want to avoid because we cannot probe
> e.g. the Zorro bus ourselves, so we dont want to reset that).
> Therefore all devices running sync will still expect sync transfers
> (with delayed acknowledges). The A3000, operating async, will wait
> forever of the acknoledge. I think the same goes for other 33C93 host
> adapters, as the chip itself doesn't include a reset output line and
> the manufacturers where to lazy to implement a independently settable
> output bit.
> My patch which tells the driver to explicitl negotiate async wasn't
> integrated with the new driver. Anyway, it wouldn't help, as the same
> drives which break the sync negotiation would break on the async
> negotiation, which is just sync negotiation with an "offset" field of
> Only think which might help would be to send a scsi reset message to
> the individual targets. But even with this one of my devices
> misbehaved... that was with the old driver, I didn't try this kind of
> funky stuff with the new one.
> So you see, its not that easy.
> I propose to include TWO generic kernels: one with sbic_inhibit_sync=1
> and one with sbic_inhibit_sync =0.
With netbsd-1.0 one had the option to switch sync-mode on/off using
the binpatch utility. This would be of great advantage to those who
don't have the space to re-compile the kernel to suit there particular
Name : Berndt Josef Wulf | Amiga 4000/40-25, 16MB, NetBSD-1.0-950902
E-Mail : email@example.com | Cybervision64 4MB , Retina-Z2 4MB,
Phone : ++61 411 245170 | Z3-Fastlane, A2065 Ethernet