On Wed, Mar 22, 2000 at 06:53:16PM -0800, Stephen Harrell wrote:
> ncr0 at pci0 dev 8 function 0: ncr 53c860 fast20 scsi
> ncr0: interrupting at irq 4
> ncr0: minsync=25, maxsync=254, maxoffs=8, 16 dwords burst, normal dma fifo
> ncr0: single-ended, open drain IRQ driver
> CACHE TEST FAILED: script execution failed.
> start=004097d0, pc=8c8c8c8c, end=004097fc
> CACHE INCORRECTLY CONFIGURED.

Our ncr(4) driver is not so great in general and is not fully
bus_dma'ified, so it has coherency problems.

I could try reconfiguring it to use I/O cycles instead of memory as
a workaround..

BTW, if you also have dmesg and /proc/pci for this system, that would
be nice to have.

> file system (default generic): ext2fs
> root on wd0e dumps on wd0b
> wd0: no disk label
> Process (pid 1) got signal 11
> Stopped in init at      0x800e3964:     jr      ra
>                 bdslot: 0x800e3968:     nop

Ok, assuming that's a Linux init binary you are running there, things
seems to be okay this far (we don't have Linux emulation on MIPS yet).

Try using the /arc snapshot binaries for a root system (netboot is
probably the most convenient).

ftp://ftp.netbsd.org/pub/NetBSD/arch/arc/snapshot/20000303/binary/sets/

Remember to replace a few files from etc/etc.cobalt and regenerate
/dev. If you don't have a separate NetBSD system with an anoncvs tree:

http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/basesrc/etc/etc.cobalt/

I too have a RaQ 2 (single ethernet and no SCSI), so you will likely
the same as me. Note the once you start stressing the system, you
will hit a weird interrupt priority bug that I have been unable to
find so far.

> at this point i ran alot of random commands nothing really gave me what I

You ended in the kernel debugger, DDB.

http://www.flame.org/cgi-bin/uncgi/hman?page=ddb&sect=4

> thought to be anything important. Soo 2 down 4 to go. I won't have time to
> do anynmore testing till probably friday. At that point I can test a qube
> 1 and 2. :)

Ok :-)


-- 
Soren