Ezra Story (ezy@panix.com) wrote:
: > 
: > Okay I have compiled the -current sources for the kernel (got them from 

did you get new binaries/libraries/includes etc.? 

: > ftp.netbsd.org) and when I am booting with the new kernel everything is 
: > proceeding as it has done under -1.0 but it gets to this point:
: > ztwobus0 at mainbus0
: > gvpbus0 at ztwobus0 rom 0xe90000 man/pro 2017/11
: > gtsc0 at gvpbus0: dmamask 0xffffff bounce pa 0x1d3058 maxdma 1024
: > scsibus0 at gtsc0
: > ahsc0 at mainbus0
: > scsibus1 at ahsc0
: > ahsc0 targ 0 lun 0: <SEAGATE ST157N          \^D|j> SCSI1 direct fixed
: > sd0 at scsibus1: 46MB, 613 cyl, 6 head, 25 sec, 512 bytes/sec
: > ahsc0 targ 1 lun 0: <SEAGATE ST251N          \^D\^K\^G> SCSI1 direct fixed
: > sd1 at scsibus1: 41MB, 818 cyl, 4 head, 25 sec, 512 bytes/sec
: > 
: > At this point the drive light is lighted on this drive and it just sits 
: > there waiting...Now I have an A3000 without any additional hardware, the 
: 
: This sounds like good old synchronous mode.  Edit
: /sys/arch/amiga/dev/sbic.c and change 
:     int sbic_inhibit_sync = 0;
: to
:     int sbic_inhibit_sync = 1;
: 
: and recompile.
:
Thats the workaround, if and only if ADOS was operating in async mode.
: 
: BTW, is there really ANY reason to have sync on by default?  The worst case
: with it off is that your drive may not be used to it maximum speed.. the
: worst case with it on is that your drive may not work at ALL.  I know which
: default .I'd. choose. :-)

If ADOS was operating in sync mode, the first async data transfer
attempted by NetBSD will lock the scsibus at:

: > ahsc0 at mainbus0
: > scsibus1 at ahsc0

The ahsc hardware (A3000 internal) and, I think, also the A2091, can't
reset the scsi bus at will - only with a CPU RESET, and in this case, we
would lose all the autoconfig boards. 

I have the same problem with a modern Quantum Fireball 1080S.

I made a patch to sbic.c to explicitly negotiate ASYNC if
sbic_inhibit_sync == 2. Unfortunately, this locks also. So I finally
started to enable debug output, read the 33c93 manual really careful and
voodoo around a bit. It looks like some intermediate status byte isn't
fetched out of the data bus register of the 33c93, and it locks up. I
made a patch for this, but it is 90% voodoo at that point, so I
hesitated to publish it.

Maybe I should just submit it as a stopgap 'til the new sbic driver is
ready. 

Regards,
	Ignatios Souvatzis