On Wed, 9 Feb 2000, NetBSD Bob wrote:

> >   That error message comes from a strange condition seen by the NetBSD
> > driver as well as the Mach driver (from which the NetBSD driver was
> > derived).  The drive appears to done a disconnect, has reconnected, and
> > the DMA transfer restarted.  Then a "bus service" interrupt occurs, but
> > the DMA transfer is still in progress and appears to be functioning
> > normally.
> 
> OK, sounds like a timing thing.  Is there a counter or something to twiddle
> to buy just a little time before the interrupt gets set?  It would seem
> that something needs to make sure that if the DMA transfer is important
> enough to require completion at that point, the other interrupts should
> not be allowed to occur until the transfer is done.  I am curious as to
> what bit in the code it is?
> 
> > ......... If I remember correctly, the 'tc' value is the remaining byte
> > count of the DMA transfer, and will vary depending on how far the transfer
> > has gotten by the time the interrupt occurs and what the original transfer
> > request size was.  The Mach driver was just noting the interrupt and
> > 'ignores' it.  The NetBSD driver also just notes the interrupt occurred
> > and continues.
> 
> I get tc values in the range of 600-1800? if I am remembering the values
> correctly, and they seem to occur mostly in the 900-1000 range.
> 
> If it is just a service message, with no particular faults, then do we
> need that in the code at that point?  Would a comment that such interrupt
> spuriousness occurs, but is not doing any damage, and then also to ignore
> it as was originally done, be appropriate?
> 
> I am curious as to on which different machines this particular spurious
> interrpt ignored message occurs?

Never got it on my 5000/133 (with 1.41) despite many kernel builds etc
etc...



> 
> Just thinking out loud again.....
> 
> Bob
> 
> 

Peter Wallace
Mesa Electronics