Hi,
Am Sonntag, den 11.01.2009, 20:22 -0500 schrieb Andy Walls:
> >
> > 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?
only on the 2.6.27.2 on the amd quad this was not enabled.
The Fedora 8 and Fedora 10 kernels do have it enabled and it seems to
make no difference and the old 2.6.22 i did not check yet.
I'll send configs and other info of all 4 machines I can test on off
list. Maybe there are ideas for stress tests to hit the supposed race.
Cheers,
Hermann
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
