On Sat, 28 Aug 1999 apr@spade.apc.aip.de wrote:

> >   That message is just an informational message.  The pmax scsi driver is
> > based on the Mach kernel driver, and seems to have also inherited the same
> > quirks as the Mach driver.  This particular case occurs when a device
> > reconnects and restarts a DMA operation.  The driver then gets a "bus
> > service" interrupt, but the DMA transfer running happily along.  The
> > driver just ignores the interrupt and the transfer seems to completes
> > normally.
...
> WHile the 1.4.1 kernel works like a charm for me I get the above kind of
> messages for a -current kernel, but usually these messages (under heavy
> disk load) are followed within a short period of time by others and
> then one or more programs simply dump core.
> Here is an extract from my logs:
> 
> Aug  9 20:55:56 spade /netbsd: asc_intr: ignoring strange interrupt tc 5078 fifo residue 3 script 1
> Aug  9 20:59:04 spade /netbsd: asc_dma_out: buflen 65536 dmalen 18724 tc 18676 fifo 12
> Aug  9 20:59:04 spade /netbsd: asc_dma_out: buflen 65500 dmalen 18724 tc 18674 fifo 12
> Aug  9 20:59:04 spade /netbsd: asc_dma_out: buflen 65462 dmalen 18724 tc 18678 fifo 13
> Aug  9 20:59:04 spade /netbsd: asc_dma_out: buflen 65429 dmalen 18724 tc 18678 fifo 13
> 
> So I was unable to use the -current kernel and returned to the 1.4.1. thing.

  Hmm, interesting.  The first message shouldn't be related to the others.
The first one occurred during a disk read operation (indicated by the
"script 1" in the message), while the remaining messages occuring during a
disk write.  The messages from asc_dma_out() definately indicate a serious
problem.  I'm going to need to refresh my memory on how that driver works
(yet again!) before I'm even sure what those messages are showing.

  Hmm again...  Let me guess - you have a 5000/200?  (Or are using a TC
option card?).  The dmalen of 18724 would be the maximum DMA transfer
length the TC SCSI option interface can do.  It also appears that
something is causing the DMA transfer to stop after transferring only a
few bytes of the requested transfer (36 bytes the first part, then 38
bytes, then 33 bytes - at which point the DMA address is going to be on an
odd byte, which may really confuse things).

  Even more interesting is that there doesn't seem to be any significant
difference between 1.4.1 and -current for the ASC driver.  I haven't been
following all the changes in the rest of the mips/pmax code, so I don't
know if there's anything there that might cause this.  One of these days
I'm going to try to get caught up and start running -current again.  Then
I can see if I experience any problems on the 5000/200 I've got.

Michael

---
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA