Re: Problems forcing async SCSI

Looking roughly in that part of the code, you might want to check out the
code that went in between 2009 (NetBSD 5) and 2012 (NetBSD 6)

Namely these two might be worth looking into
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amiga/dev/wdc_amiga.c.diff?r1=1.33&r2=1.34&only_with_tag=MAIN&f=h
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amiga/dev/ahsc.c.diff?r1=1.36&r2=1.37&only_with_tag=MAIN&f=h



On Mon, Aug 29, 2022 at 8:10 PM John Klos <[email protected]> wrote:

> Hi,
>
> I have an Amiga 3000 which I've been trying to get to be happy forever.
> After a full recap, some repairs and the discovery and fix of a physical
> issue with SCSI, I thought it'd finally be happy.
>
> However, I could not get NetBSD working consistently on this machine
> except when I used SCSI on a Cyberstorm (I'm currently running with the
> built-in m68030). The built in SCSI and an A2091 work well without
> problems in AmigaDOS, but NetBSD hangs either when scanning the SCSI bus
> or right after reporting a found SCSI drive.
>
> I've ruled out any sort of termination issues by trying using on-board
> terminator resistor packs, both passive and active termination on the
> cables, using disk's termination, trying different disks, et cetera. No
> issues with that. I also made certain the NVRAM preference for sync mode
> was disabled, too.
>
> I then realized that both the A2091 and the Amiga 3000 use the 33C93 SCSI
> controller. The A3000 has the -8 version of the chip, so I'm guessing it's
> not a problematic SCSI chip.
>
> I tried disabling sync mode while booting NetBSD (netbsd -I 0xff) as per
> the boot man page:
>
>       -I mask
>             inhibit sync negotiation as follows: The mask is a bitmap
> expressed
>             in C notation (e.g., 0xff) with 4*8bits, each bit, if set to 1,
>             disabling sync negotiation for the corresponding target.  Note
> that
>             this only applies to (some of the) real SCSI busses, but not,
> e.g.,
>             to internal IDE.  The bytes are used up from right to left by
> SCSI
>             bus drivers using this convention.
>
> but no matter what I tried, the kernel still tries to negotiate sync mode:
>
> [    1.0000030] ahsc0 at mainbus0
> [    1.0000030] scsibus0 at ahsc0: 8 targets, 8 luns per target
> ...
> [    1.0355564] scsibus0: waiting 2 seconds for devices to settle...
> [    3.5655092] ahsc0: target 1 now synchronous, period=208ns, offset=12.
>
> It hangs here with SCSI LED brightly lit.
>
> Same with loadbsd, which appears to want just "-I ff":
>
>       -I mask
>             inhibit sync negotiation as follows: The mask is a bitmap
> expressed
>             in hexadecimal (e.g., ff) with 4*8bits, each bit, if set to 1,
>
> Instead of wondering if my hardware is the issue (after all, would both
> the A3000 and the A2091 fail in exactly the same way?), I wondered if
> older NetBSD works. NetBSD current, 9, 8, 7 and 6 all have the same issue,
> but NetBSD 5.2.3 booted just fine, even with synchronous mode:
>
> ahsc0 at mainbus0
> ...
> ahsc0: target 1 now synchronous, period=208ns, offset=12.
> sd0 at scsibus0 target 1 lun 0: <ATA, Samsung SSD 850, 106P> disk fixed
> sd0: fabricating a geometry
> sd0: 232 GB, 238475 cyl, 64 head, 32 sec, 512 bytes/sect x 488397168
> sectors
>
> I let it run for hours while doing lots of disk I/O (untargzipping
> pkgsrc.tar.gz, for instance) without any issues.
>
> To see if this really has to do with synchronous mode, I booted newer
> kernels (9.3, 9.99.99) with an older flash card in a flash-card-to-SCSI
> adapter that won't negotiate synchronous mode, and it booted and ran just
> fine, also for hours:
>
> [   1.0000050] ahsc0 at mainbus0
> [   1.0000050] scsibus0 at ahsc0: 8 targets, 8 luns per target
> ...
> [   1.0419880] scsibus0: waiting 2 seconds for devices to settle...
> [   4.2717043] sd0 at scsibus0 target 0 lun 0: <SCSI, PCCARD Flash, 1.28>
> disk removable
> [   4.5416940] sd0: 61064 MB, 16383 cyl, 15 head, 63 sec, 512 bytes/sect x
> 125059072 sectors
> [   4.5717048] sd1 at scsibus0 target 0 lun 1: <SCSI, Compact Flash, 1.28>
> disk removable
> [   4.6216664] sd1: drive offline
> [   4.6516632] sd2 at scsibus0 target 0 lun 2: <SCSI, SmartMedia, 1.28>
> disk removable
> [   4.6937999] sd2: drive offline
> [   4.7616884] sd3 at scsibus0 target 0 lun 3: <SCSI, Secure Digital,
> 1.28> disk removable
> [   4.8216974] sd3: 61056 MB, 15506 cyl, 128 head, 63 sec, 512 bytes/sect
> x 125042688 sectors
> [   4.8616941] sd4 at scsibus0 target 0 lun 4: <SCSI, Memory Stick, 1.28>
> disk removable
> [   4.9016978] sd4: drive offline
> [   6.5216733] 4 views configured
> [   7.1616275] sd1(ahsc0:0:0:1):  Check Condition on CDB: 0x00 20 00 00 00
> 00
> [   7.2063902]     SENSE KEY:  Not Ready
> [   7.2216519]      ASC/ASCQ:  Medium Not Present
> [   7.2517130] sd2(ahsc0:0:0:2):  Check Condition on CDB: 0x00 40 00 00 00
> 00
> [   7.2987175]     SENSE KEY:  Not Ready
> [   7.3036288]      ASC/ASCQ:  Medium Not Present
> [   7.5116608] sd4(ahsc0:0:0:4):  Check Condition on CDB: 0x00 80 00 00 00
> 00
> [   7.5519006]     SENSE KEY:  Not Ready
> [   7.5667991]      ASC/ASCQ:  Medium Not Present
> [   7.6416550] root on sd0a dumps on sd0b
>
> So... Does anyone else run a system with 33C93 SCSI in synchronous mode?
> Any thoughts about why it's always trying to negotiate synchronous mode,
> even when asked not to?
>
> Any ideas why synchronous mode works with NetBSD 5.2.3 but nothing newer?
>
> In the meanwhile, I'll be happy to use this flash card SCSI device :)
>
> Thanks,
> John Klos
>