[ On Saturday, March 26, 2005 at 18:16:17 (-0500), Thor Lancelot Simon wrote: ]
> Subject: Re: isp(4) with Q-Logic 2340 suffers "stray interrupts" under load (was: does "stray ... irq; stopped logging" also mean stopped interrupts?)
>
> > [ On Saturday, March 26, 2005 at 12:05:56 (-0700), Michael L. Hitch wrote: ]
> > > Subject: Re: does "stray ... irq; stopped logging" also mean stopped interrupts?
> > >
> > > Oh, then what about this:
> > > 
> > >                 if (ALPHA_SHARED_INTR_DISABLE(dec_6600_pci_intr, irq))
> > >                         dec_6600_intr_disable(irq);
> > >                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

> I'm no expert on the Alpha interrupt code, but it seems to me that that
> interrupt disable should go.

Me neither and unless someone who is speaks up about why it's important
to disable interrupts that aren't (always) being claimed by a driver, I
agree it's safest just to leave them enabled.  Indeed perhaps even
critical, especially given that I've been reminded by a recent
recurrance that I've also seen the occasional "stray isa irq 4" for:

	com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
	com0: console

I sure don't want that thing going dead on me at any time!

Commenting out those two lines Michael referred to above certainly
helped with this isp(4) driver problem.  I've shuffled well over a
million little files about on and between these two RAID arrays since
then and everything still seems intact and working with no data loss nor
other perceptible misbehaviour on the isp devices.

It would be good to know why the card is sending these "stray"
interrupts though and why the driver ignores or can't see them.  Perhaps
the ISR "fixes" (e.g. dec/ic/isp.c revision 1.97) were not quite complete?

(It wouldn't hurt to know why the com(4) driver misses the occasional
interrupt too!)

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>