Re: better leve triggered IRQ management needed

[Neil Brown]

On Saturday April 29, torvalds@xxxxxxxx wrote:
> 
> 
> On Sun, 30 Apr 2006, Neil Brown wrote:
> > 
> > So what do you propose should be done to better handle such poorly
> > built machines?
> 
> Well, the thing is, there's not a lot we _can_ do.
> 
> We can try to report it. We can also try to handle it as gracefully as we 
> can.
> 
> > As a concrete example I have a notebook which definitely assigns
> > shared interrupts to IRQ-10 (See /proc/interrupts below) yet the ELCR
> > only flags IRQ-11 as being level triggered and the rest are edge
> > triggered.
> 
> Also, do you have the option to enable the IO-APIC? Maybe it's already 
> enabled, and your BIOS has just disabled it, but your /proc/interrupts 
> implies that you may have compiled your kernel without UP_APIC support.
> 
> With the APIC, we might be able to do better. Worth trying out.
> 

I have tried compiling with APIC and ACPI support (in various
combinations) and neither make a noticeable difference.  I haven't
looked at the BIOS setting yet, though I don't remember seeing
anything like that (it's been a while though).


> > And with this configuration I definitely lose interrupts to the
> > wireless ethernet (ra0).
> > 
> > How do I make this work reliably?
> > I could:
> > 
> > 1/ modify handle_IRQ_event so that it is more resilient to the
> >   possibility that shared interrupts are edge triggered.  This can be
> >   done be iterating over all action->handlers until they all return
> >   IRQ_NONE.
> 
> Well, yes. It's worth trying, but as mentioned, we have some drivers that 
> return IRQ_HANDLED just because the driver conversion has been lazy. So 
> limit it to a few things.

I tried it and it solved my problem.  However I appreciate that would
be a risky change for the reasons you mention.

> 
> Anyway, I also do wonder if your irq lossage is due to something else.
> 

Maybe.  But all the symptoms I have found are completely consistent
with them being edge triggered.  That's no proof of course....


> On the XT-PIC, disabling the irq will cause an edge when it's re-enabled, 
> so you can get the "level" behaviour by disabling the irq over the irq 
> handler.
> 
> And that's exactly what we do, if I recall correctly. It's been years 
> since I worked with that code, but looking at it quickly, it seems to 
> match my recollection.
> 
> > 2/ Arrange that the ELCR bit is set for any IRQ for which a shared
> >   interrupt is registered (on the basis that the code for handling
> >   shared interrupts is not resilient against them being edge triggered).
> 
> NO.
> 
> How many times do I have to say this?
> 
> Yes, ELCR sets edge vs level.
> 
> BUT IT ALSO SETS THE POLARITY.  If you switch the bit around, it will also 
> switch the polarity, and IT WILL NOT WORK. Because you'll end up with a 
> level-triggered interrupt that is level-triggered for the wrong polarity, 
> and will trigger whenever there is _not_ an interrupt pending.

The thing is: This is exactly what I am currently doing to solve the
problem.
I hacked my kernel to flip the '10' bit, and the problem went away.


> 
> Now, I will almost guarantee you that there is an exception to this rule 
> (hey, it's PC hardware, there's _always_ an exception to any rule ;), and 
> on some situations, the ELCR thing will truly only affect edge vs level.
> 
> But the point is, we can't just switch to level triggered. There simply is 
> no such hardware in general for the old PC interrupts.
> 
> (Now, _if_ you use the APIC, you can actually switch polarity and trigger 
> mode independently. Which is one reason why I'd like to hear whether you 
> perhaps have just disabled the APIC by mistake, rather than have a nasty 
> BIOS that disables it for you).
> 

I'll see what I can find, and report back if I find anything
interesting.

Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/