Subject: scsi problem
To: None <port-pmax@sun-lamp.cs.berkeley.edu>
From: Charlie Root <root@snowhite.cis.uoguelph.ca>
List: port-pmax
Date: 05/17/1994 15:10:43
Just out of curiosity, are you using the older pmap code that I passed along
or Ralph's newer stuff that would be on 4.4lite? Why I ask is that I have
seen a similar scsi problem when using the newer pmap module code, that
I was never able to resolve, but would not show up when running the older
(2 way set associative cache of pte entries) pmap module.

The problem had the following bizarre properties:
- only happened for RZ23 (never for an RZ24 on an otherwise identical setup)
- the RZ23 would intermittently fail to change phase (I'm a scsi midget, but
  I am referring to the three signals I/O, C/D and MSG I/O that are driven
  by the target, ie. RZ23) when expected
- the problem would happen on both a 2100 and a 5000/120 (different scsi
  interfaces!)
- the problem would go away when I changed to the old pmap module kernel
  that had very few other differences and used identical rz.c and scsi
  interface (sii.c or asc.c) drivers (note above that it happened for
  BOTH the sii.c and asc.c)

If this is what has bit you, you might be able to get around it by using a
different type of scsi disk. The only explanations I can suggest are:
- some kind of timing problem, but I can't think of what??
- a wild pointer in the newer pmap code that sometimes stomps on data
  used by the scsi drivers

As you can see, I am not a big fan of scsi (as poor Ralph could attest,
from dealing with me before).
Good luck with it and let me know if you have any progress, rick

------------------------------------------------------------------------------