On Monday 18 January 2010 23:07:31 Andy Walls wrote:
> 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.
Actually, I'm only getting more confused. The Linux Device Drivers book says
something quite different from what I gather from this thread. And the thread
itself fizzles out too without much of a conclusion. Apparently the consensus
seems to be that this flag should be removed, but it's pretty fuzzy on what
the consequences of that removal would be.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
