On Mon, 2010-01-18 at 16:35 -0500, Andy Walls wrote: > On Mon, 2010-01-18 at 16:14 -0500, Jay R. Ashworth wrote: > > ----- "Andy Walls" <[email protected]> wrote: > > > On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote: > > > > > > > There is no particular order to these items. Most of these are hard > > > or time > > > > consuming to do. Otherwise I'd have done them by now :-) > > > > > > > > - Both cx18 and ivtv use IRQF_DISABLED when registering the irq. > > > This flag is > > > > bogus (and produces this annoying message in the log: > > > 'IRQF_DISABLED is not > > > > guaranteed on shared IRQs'). Note that many drivers do this. This > > > is something > > > > I discovered only recently. > > > > > > I naively asked near the end of this discussion on the LKML what is > > > the > > > preferred solution to fix the "problem": > > > > > > http://lkml.org/lkml/2009/11/30/486 > > > > > > No one answered. The whole thread was about the problem with > > > IRQF_DISABLED not being honored and the need to run with interrupts > > > disabled. > > > > I have heard it said that some developers appreciate a reminder if an LKML > > conversation about their hobby horse seems to be passing them by. Without > > my reading the whole thread, is such a target apparent? > > My parser broke on your question. > > However, this part of the discussion by Tom Glexiner (the RT Linux guy) > asks what I think are the right questions: > > http://lkml.org/lkml/2009/11/30/215 > > That said, now I'm going to go back and read the whole thread just to > come back up to speed on all the issues. > > Regards, > Andy >
And here's an older thread on the same issue: http://lkml.org/lkml/2009/3/2/33 It appears to me the real question is "what should be the kernel default when you have a shared IRQ with two types of handlers, one that needs to run with IRQs enabled and one that doesn't?" There seems to be an easy answer, according to Peter Zijlstra: "People are playing odd games with IRQF_DISABLED, remove it. Its not reliable, since shared interrupt lines could disable it for you, and its possible and allowed for archs to disable IRQs to limit IRQ nesting. Therefore, simply mandate that _ALL_ IRQ handlers are run with IRQs disabled. [ This _should_ not break anything, since we've mandated that IRQ handlers _must_ be able to deal with this for a _long_ time ] IRQ handlers should be fast, no if buts and any other exceptions. We also have plenty instrumentation to find any offending IRQ latency sources." Then Russel King for example trots out a simple valid (to me) counter example: http://lkml.org/lkml/2009/3/2/225 "Bad. Very bad. So, when I use PIO IDE on embedded platforms, I have to have all other interrupts locked out for things like serial ports, network interfaces with small packet buffers, etc and I can't specify IRQF_DISABLE on such network interfaces anymore?" So there appears to be a tension between the embedded systems case (single processor with devices with hardware and resource limits) and the desktop/server case (multiple processor with very capable hardware). Hans, Now I understand your question better, if you were thinking along an embedded system context. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
