Slow IRQ handling? (was: Nova-T, cx88-dvb & "cx88_wakeup: 2 buffershandled (should be 1)")

[Hanno Zulla]

Hi,

[ please cc me. Thanks. ]

> I've added the printk some years ago.  I stopped maintaining v4l/dvb
> bits two years ago, so it's a bit a shot into the dark because I have no
> idea what has changed recently in the driver.

Indeed, it appears that this driver has no maintainer right now. (Or the
maintainer is on holidays. I had no luck finding an active maintainer
via the linux-dvb mailing list or via email in the past weeks).

> The message is in no way critical, the driver should cope just fine with
> the situation, and as usually some more buffers are queued for dma it
> also doesn't imply dvb stream data got lost.  It seems in your case some
> data actually got lost though, otherwise the effect wouldn't be visible.
>
> Background:  The card raises an interrupt for each filled buffer, so in
> theory each time the irq handler runs it should handle a single buffer.
>  If it is more than one it means the irq handler wasn't called in time
> or wasn't called at all for some reason.

Thanks for clarifying this.

> Could be someone in the kernel blocked interrupts for a insane long
> time, so the hardware managed to fill the one more buffer before the irq
> handler was actually called.  Could be IRQ handling in the cx88 driver
> is screwed.  Could be a scheduling issue (Is this a core2 duo?  If so
> check the longish discussion on about that here in lkml, subject "long
> freezes on thinkpad t60").

Yes, it is a Core2Duo with an Intel chipset.

http://launchpadlibrarian.net/8283450/cpuinfo

However, a user with a single-core AMD cpu and a VIA chipset reports the
same problem.

http://launchpadlibrarian.net/8283450/cpuinfo

See
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/119115
for more info.

> Could also be the irq handler for the other device sharing the same irq
> being very slow.  Any pattern here that it is linked to some specific
> device sharing the irq?

No idea, I did not see any pattern here. Also, the problem on my system
appears with every PCI slot I tried.

What do you suggest? How can I debug this issue so that you kernel guys
can look into it?

Thanks,

Hanno
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/