My assertion was probably based on out of date information or the statements
of someone who was confusing your NCR driver with some other driver. I
looked at the latest NCR driver code and what you say is correct.
> > read the de4x5 docs, it turns out the de4x5 driver has a workaround to
> > reallocate that interrupt as a SA_SHIRQ on the behalf of an already loded
> > SA_INTERRUPT based driver. It seems this workaround is flawed, since it
> > breaks if it's twiddling the IRQ handler for an IRQ that's already shared by
> > two devices. Thus, it hoses my SCSI card.
> >
> > I have no idea why this workaround occurs anyway, since my aic7xxx _should_
> > be allocating a SA_SHIRQ unless there's a flaw at around line 7912 that's
> > causing it to allocate a SA_INTERRUPT for additional cards (if this is even
> > possible)
>
> Linux was messed up for IRQ sharing due to the SCSI subsystem having
> chosen SA_INTERRUPT at the beginning, and people who had implemented such
> kind of stupid things you described (they called work-around) just added
> shit to shit, in my opinion.
It seems that the de4x5 driver is doing this "workaround" incorrectly and
thus hosing the interrupt handler for the second aic7xxx card on that
interrupt. The de4x5 driver should certainly not enable its hack in this
case. My question is, is the de4x5 incorrectly detecting a SA_INTERRUPT irq
handling by the aic7xxx driver, or is the aic7xxx driver incorrectly using
this mode for the second card? I've cc'd this to the aic7xxx list so perhaps
Doug or someone else can comment on this further. If all else fails, I'll
add tons of printk()'s until I get things sorted out.
I also can't tell if the tulip driver refuses to let me ifconfig the first
port because it can't find the eeprom (quite possible - maybe I'll try
recompiling it with the reverse scan option) or because it can't get an IRQ.
>
> > If you want the same effect for the tulip driver, find SA_INTERRUPT in the
> > source and change it to SA_SHIRQ and see if this works. I have no idea why
> > this is not the default (aside from the relatively tiny performance penalty
> > it incurs)
>
> If you elect to change interrupt flags on a driver, you must ensure that
> interrupt masking is fine for the new interrupt flags. For example, if you
> remove the SA_INTERRUPT flag, you must check that the tampered driver does
> mask interrupt when interrupts needs to be masked, or make appropriate
> changes to the driver code.
>
It's perhaps just lucky coincidence that this used to work for older
versions of the aic7xxx driver before this was the default behavior. You're
completely right though: With other drivers a meltdown might occur if
another IRQ happened at a bad time.
-- Brian Ristuccia brianr@osiris.978.org bristucc@baynetworks.com bristucc@cs.uml.edu- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/