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. 

	Ignatios Souvatzis