Port-amiga archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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 <john%ziaspace.com@localhost> 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


Home | Main Index | Thread Index | Old Index