Subject: Re: crashing ncr5380 SCSI on 3/60 (was Re: Overclocking)
To: None <duncanm@qsa.qualitysemi.com>
From: None <gwr@NetBSD.ORG>
List: port-sun3
Date: 06/16/1998 11:07:36
> From: duncanm@qsa.qualitysemi.com
> Date: Tue, 16 Jun 1998 10:40:20 +1000
> 
[...]
>   I am having a problem with my 3/60 which appears to be related to
> system clock speed, but I can't fathom why (and I don't
> currently have my 3/60 running NetBSD enough to do recompiles,
> so I can't check it out too much).

So, does the same machine work OK with the stock 20MHz clock?

> The scenario:
> 
>     A 3/60, [...] NetBSD-1.3 (6Jan'98 compile) GENERIC.
>     [...] 25MHz system clock [with new CPU+FPU ...]
> 
>     Under NetBSD, the system will boot ok and run for
> a short time (say 10mins) before crashing as follows:
> (I have never seen this problem @20MHz)
> 
>      si: DMA timeout (while polling)
>      si0: aborting, but phase=DATA_OUT (reset)
>      si0: reset SCSI bus for TID=0, LUN=0
>      panic: ncr5380_scsi_cmd: polled request, abort failed
>      Stopped at - Debugger+0x6: unlk a6
[...]

>   Having a poke around, and given the above, I see that
> delay_divisor (in sys\arch\sun3\sun3\sun3_startup.c) is
> suitable for a 25MHz clock, so I see no problem with this.

If you have upgraded the clock, you may need to adjust the
delay_divisor initialization in the switch statement where
case SUN3_MACH_60: appears.

Of course, delay_divisor should eventually be determined by
dynamic means.  It's just not high on my priority list.

> I note that in sys\dev\ic\ncr5380.doc (yes! doco is so useful):
> under Known Problems:

Well... Maybe useful, maybe misleading...

> "Timeouts in the driver are EXTREMELY sensitive to the
> characteristics of the local implementation of delay().
> The Sun3 version delays for a minimum of 5us.  However,
> the driver must assume that delay(1) will delay only
> 1us.  For this reason, performance on the Sun3 sucks in
> some places."

Actually, it only sucks when doing PIO, which is rare.
The Sun3 SCSI boards have DMA that works, thankfully!

>     Any way to patch the sun3 code so that delay() behaves
> consistently with a clock speed other than 20MHz?  Why does
> this not cause problems on the faster-clocked sun3's?

In the SCSI driver (and in general) it is acceptable for any
delay() call to take longer than the specified time.  It is
an artifact of the delay() implementation that any request
for a delay of less then 5uS. takes 5uS.  Not a problem,
as long as delay() takes at least as long as requested.

Gordon