On Mon, 2009-01-12 at 11:13 -0800, Trent Piepho wrote: > On Sun, 11 Jan 2009, Andy Walls wrote: > > On Mon, 2009-01-12 at 00:54 +0100, hermann pitton wrote: > > > Am Samstag, den 10.01.2009, 22:05 -0500 schrieb Andy Walls: > > > > On Sun, 2009-01-11 at 03:32 +0100, hermann pitton wrote: > > > > > Am Samstag, den 10.01.2009, 07:37 -0500 schrieb Andy Walls: > > > > > > On Sat, 2009-01-10 at 13:02 +0100, Marcin Slusarz wrote: > > > > > > > On Fri, Jan 09, 2009 at 09:48:07PM -0500, Andy Walls wrote: > > > > > > > > but not clearing the state of SAA7134_IRQ_REPORT, maybe something like > > > > > > > > this (I don't have a SAA7134 datasheet): > > > > > > > > > > > > > > > > saa_writel(SAA7134_IRQ_REPORT, 0xffffffff); > > > > > > > > > > > > > > > > So when saa7134_initdev() calls request_irq(..., saa7134_irq, > > > > > > > > IRQF_SHARED | IRQF_DISABLED, ...), it gets an IRQ that is shared with > > > > > > > > another device. > > Keep in mind that PCI writes are posted, so 'writel(...);request_irq(...);' > might result in the irq being requested (which only involves the CPU and > kernel) before the device receives and processes the write (which involves > the CPU, pci bridge(s), and the saa7134 device). Yeah, but the next read back will flush the write through the bridge - PCI ordering rules. > IMHO, a better solution is to just not request the irq until the driver is > read to handle interrupts. That seems a lot safer than depending on the > irq handler not doing anything bad if it's called while the driver is still > initializing. Yes. Agree. I was looking for something simple. I see Mauro already applied my little one liner. It won't do any harm (clears the report register after disabling notifications), but a more deterministic inhibition of the saa7134_irq() handler until really ready would be safer. > > > Andy, I allowed shared interrupts on several machines with multiple > > > saa713x cards and current v4l-dvb, but I'm still not able to reproduce > > > the oops. So can't try the fix. Who has the oops and can try? > > What you need to have is the saa713x sharing an interrupt with a different > device which generates a lot of interrupts while the saa713x driver is > being loaded. Even then it's a race and isn't going to happen every time. Agree. > > 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? > > I have no doubt that the original idea that SAA7134_IRQ_REPORT isn't clear > when the driver loads is correct. Why shouldn't the bits be set? And if > they are, we should see an Oops that looks exactly like this one. Yes, my thoughts. Regards. Andy -- 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
