I just recently purchased a Weitek POWER uP chip to replace the CPU in my
SPARCstation 2, running release 1.1.  I did some research before I bought it
because I did not want to buy something that would require radical kernel
alteration.  I also downloaded the entire archive of this list and searched
for problems discussed here that pertain to it. 

What I did find may be quite helpful to those of you who have been having 
rare SCSI problems with the chip installed.  During my 'digging' up 
phase, I discovered that Weitek has admitted to a bizzare 'feature' in 
their chips.  When a Weitek chip experiences a window register underflow, 
it may occasionally issue a spurrious read from the address located in 
register %o7.  Normally a spurrious read does no harm to the state of the 
system.  However there is one case on the Sparc motherboard where this is 
not true - the esp SCSI chip.

A read from one of the registers on the esp chip causes it to reset its 
state.  More specifically, I think this is the way interrupts are 
acknowleged by the driver.  If the routine that reads from the esp 
register happens to leave the register address in %o7, there is a 
remote possibility that the CPU will issue a bus fetch from that address 
when you least expect it.

This would explain processes that are stuck in 'D' state.  Imagine that such
a process has requested some I/O that requires a flush to disk.  The top 
half of the driver enters the write request into the queue and waits for the
request to be serviced before returning to the user process.  Normally 
the esp chip will interrupt once the request is done, which is the signal 
that the kernel uses to return to the user process.  However if this 
interrupt is ackowledged inadvertantly by one of these spurrious reads, 
it will be lost and the requesting process will hang forever.

So what do you think?  Does this sound plausible?  I've already inserted 
a few 'asm(" clr %o7");' lines into last lines of the esp driver 
functions which read the register directly.  Although when I looked at 
the assembly output of the driver, searching for anything that access 
%o7, I found nothing.

In any case, I'm curious to know what everyone thinks,
-J