Hi!

> > Did anyone test 1.3.2 on a 5000/200?  We know it works with 1.2G drivers
> > and doesn't on 1.3.3...  I'm trying to narrow down exactly where the
> > problem is and get it fixed for 1.3.4 (which will freeze in approx. one
> > week).
> 
> I had just a look at pr 5510, which describes this problem the first
> time, and it states that the problem is already in 1.3.1. The pr
> has also some appendix with analysis of Michael Hitch, so maybe its
> a good idea to have a closer look at whats there before trying to hunt
> it.

I am one of the guys suffering from the problem. two or three times there
was some traffic on this (port-pmax) list regarding this problem.

Recent research I did led to the following:
---------------------------------------------------------------------------
Message-Id: <19981225091102.13504.qmail@spade.apc.aip.de>
[...]
Subject: Re: Current PMAX 5000/200 SCSI oddity
To: mhitch@lightning.oscs.montana.edu (Michael L. Hitch)
Date: Fri, 25 Dec 1998 10:11:02 +0100 (MET)
Cc: port-pmax@netbsd.org
[...]
 
>   I've still got Greg's diffs between an older version of the asc driver
> that worked, and the one that was failing when I was working with him on
> these problems.  I guess it's time to dig out those changes and try to 
> determine exactly what had changed and how it might affect this particular
> problem.  Since I'm about to leave for 2 weeks, I probably won't be able
> to even look at this until the 2nd week in January.

This would be really fine.
Maybe the following information can be of any help:

The last working kernel I was able to make on my 5000/200 was made on 
May 18th; and the first "bad" kernel after this is from May 21st.
I supped kernel and userland on May 16th 14:24 CET (I use sup.de.netbsd.org,
which maybe has some minor delay) and then again on May 21st 14:53 CET.

Grabbing trough the list of files transferred the only relevant files seem
to be sys/arch/pmax/dev/sii.c and sys/arch/mips/include/trap.h.
Both had changed in the May 21st sup.

Anyway it is my impression that I had a even better kernel several months
before.
The kernel made on May 18th gives me messages like

 /netbsd: asc_intr: data overrun: buflen 4096 dmalen 4096 tc 4040 fifo 15

about once a week during heavy disk activity and then reboots.
But this I think is already a different story.
---------------------------------------------------------------------------

No idead if this helps.
Unfortanately I am not a programmer or kernel specialist, so all
I can do is describing the problem.

Greetings,

Andreas