> In <199805190715.DAA01543@cs201.wmich.edu>
> naamato@cs.wmich.edu wrote:
> > I just threw a 48Mhz oscillator at U110 (replacing the 40 MHz
> > one) on my 3/60.  I'm seeing some very strange behavior.
> > a)  Has anyone been successful with this procedure?
> I used 3/60 with 50MHz oscillator few years ago.
> It almost worked fine, but sometimes dumped cores
> with signal 4 and 11 in summer. ;-)
> I think faster SIMMs(~80ns), faster CPU/FPUs (25MHz?)
> and cooling chassis fans are recommended.
> BTW, if you use NetBSD/sun3 on the overclocked machines,
> you'd better modify delay_divisor value.
> (now it seems in sun3/locore2.c)
> ---
> tsutsui@ceres.dti.ne.jp


  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).

The scenario:

    A 3/60, which I have dual booting SunOS4.1.1 and
NetBSD-1.3 (6Jan'98 compile) GENERIC.

    I recently replaced the master clock with a 50MHz
part (ie: 25MHz system clock). No problems
under SunOS as far as I can tell for the last couple of
months (the CPU/FPU are 50MHz parts, so there's no problem there)

    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

thereafter, the system will boot ok until it fscks /dev/sd0a
and then will (reliably) crash with the same problem at the
end of the fsck. The only solution is to power down for a
time (suggesting that it is also temperature related).

  TID=0/LUN=0 is an ESDI bridge in a shoebox to an old
Toshiba MK156F

  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.

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

"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."

    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?


rgds

     duncan