Ignatios Souvatzis writes:
> 
>    Date: Thu, 2 Nov 95 22:45:53 CST
>    From: bruce@zuhause.mn.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
> zero. 
> 
> 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
system configuration.

Comments?

cheerio Berndt
-- 
Name    : Berndt Josef Wulf        | Amiga 4000/40-25, 16MB, NetBSD-1.0-950902
E-Mail  : wulf@hotdog.apana.org.au |       Cybervision64 4MB , Retina-Z2 4MB,
Phone   : ++61 411 245170          |       Z3-Fastlane, A2065 Ethernet