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. As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really a problem in the kernel's management of interrupt handlers and has been labled as "do not fix". Hence we have a useless message being printed out, warning users of a condition that has been in existence long before the message existed, for which there is no agrred upon solution in sight. The user can't fix it short of moving hardware around. I'm pretty sure a driver can't fix it without either: a. refusing to work at all (no good for users) or b. running it's IRQ handler with interrupts enabled (no good for multimedia capture devices, you'll just drop frames for no good reason) So there the warning message sits. Did I get it wrong? Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
