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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
