>
> So "dev->input" is NULL when saa7134-tvaudio.c:mute_input_7133() is
> called and that is what causes the Oops. It was called by the
> saa7134_irq() handler trying to take action, shortly after request_irq()
> was called. Can you think of why this would happen?
>
Hermann,
I just looked at request_irq() on my Fedora 7
int request_irq(unsigned int irq, irq_handler_t handler,
unsigned long irqflags, const char *devname, void *dev_id)
{
[...]
#ifdef CONFIG_DEBUG_SHIRQ
if (irqflags & IRQF_SHARED) {
/*
* It's a shared IRQ -- the driver ought to be prepared for it
* to happen immediately, so let's make sure....
* We do this before actually registering it, to make sure that
* a 'real' IRQ doesn't run in parallel with our fake
*/
unsigned long flags;
local_irq_save(flags);
handler(irq, dev_id);
local_irq_restore(flags);
}
#endif
[...]
Maybe the kernels with the reported oops were built with
CONFIG_DEBUG_SHIRQ set, which will call the saa7134_irq() handler
immediately. CONFIG_DEBUG_SHIRQ is obviously intended to "smoke out"
device driver irq handlers that could experience an intermittent oops
with shared irqs.
Maybe you could enable this in you kernel and reproduce the Ooops?
Regards,
Andy
> I don't know. If no one here can test it and confirm a fix, maybe we
> just forget about it until someone with hardware complains?
>
>
> Regards,
> Andy
>
> > Thanks,
> > Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
