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/
