"Michael L. Hitch" wrote:

> On Fri, 27 Aug 1999, David Brownlee wrote:
> 
> > On Fri, 27 Aug 1999, Mauricio Tavares wrote:
> > 
> > > [...]
> > > Automatic boot in progress: starting file system checks.
> > > /dev/rrz0a: file system is clean; not checking
> > > /dev/rrz0d: file system is clean; not checking
> > > /dev/rrz0f: file system is clean; not checking
> > > asc_intr: ignoring strange interrupt tc 8154 fifo residue 3 script 1
> > > setting tty flags
> > > asc_intr: ignoring strange interrupt tc 990 fifo residue 3 script 1
> > >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >   Is that some kind of problem with the code for the SCSI interface?  If so,
> > >   it makes me think that I got the wrong version of the kernel even though
> > >   I used the one that *was* in the current source tree.  Could I have
> > > missed   the one Simon has corrected?
> > 
> > 	Definitely looks live a scsi drive issue. For entertainment value
> > 	you could probably check termination and cables, but I think
> > 	someone who knows something about the pmax scsi driver is going
> > 	to have to answer that one :)
> 
>   I guess that 'someone' must be me :-)
> 
>   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.

If this is just informational, should be make it "ifdef DEBUG"?

Simon.