Nova-T, cx88-dvb & "cx88_wakeup: 2 buffers handled (should be 1)"

Nova-T, cx88-dvb & "cx88_wakeup: 2 buffers handled (should be 1)"

[Hanno Zulla]

Hi,

[ please cc me with replies. ]

I have asked this upstream at linux-dvb [1] and to the Ubuntu kernel's
bugtracker [2], but no help so far. Googling around, one can find other
reports about this, but no solution, either.


Using a Nova-T dvb card, I get the following in /var/log/messages...

22:09:54 kernel: cx88_wakeup: 2 buffers handled (should be 1)
22:09:57 kernel: cx88_wakeup: 2 buffers handled (should be 1)
22:10:06 kernel: cx88_wakeup: 2 buffers handled (should be 1)
22:10:09 kernel: cx88_wakeup: 2 buffers handled (should be 1)
22:10:12 kernel: cx88_wakeup: 2 buffers handled (should be 1)
22:10:15 kernel: cx88_wakeup: 2 buffers handled (should be 1)

...every few seconds while watching TV with xine or other dvb-apps. The
event results in a visible interruption of the video stream.


Looking on the net for solutions, I tried these:

- changing pci latency in the bios settings

- putting the card into a different pci slot

- using "pci=routeirq" or "pci=noacpi" kernel boot parameters

NONE of these solved the problem.

Please see [2] for more info.


The problem appears with three different recent Linux distribution
kernels: Ubuntu 2.6.22-7-generic, Ubuntu 2.6.20-15-generic, Suse
2.6.18.2-34-default.

The problem is not hardware-specific, it appears with an Intel CPU and
Intel chipset as well as with an AMD CPU and a VIA chipset.

The problem appears to be shared irq resources [3]. However, my
mainboard doesn't allow to choose specific irqs for pci slots and
anyway, shared irqs shouldn't break this dvb card, in the first place.


What else can I try?


Thanks for any help,

Hanno


[1]
http://www.linuxtv.org/pipermail/linux-dvb/2007-May/018232.html
http://www.linuxtv.org/pipermail/linux-dvb/2007-July/018881.html

[2]
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/119115

[3]
http://launchpadlibrarian.net/8036103/lspci-vvnn.log
http://launchpadlibrarian.net/8283449/lspci-vv.log

Re: Nova-T, cx88-dvb & "cx88_wakeup: 2 buffers handled (should be 1)"

[Gerd Hoffmann]

> Using a Nova-T dvb card, I get the following in /var/log/messages...
> 
> 22:09:54 kernel: cx88_wakeup: 2 buffers handled (should be 1)

> ...every few seconds while watching TV with xine or other dvb-apps. The
> event results in a visible interruption of the video stream.

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.

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.

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").

> The problem appears to be shared irq resources [3]. However, my
> mainboard doesn't allow to choose specific irqs for pci slots and
> anyway, shared irqs shouldn't break this dvb card, in the first place.

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?

cheers,
  Gerd

Slow IRQ handling? (was: Nova-T, cx88-dvb & "cx88_wakeup: 2 buffers handled (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

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

[Mauro Carvalho Chehab]

Hi Hanno,

Em Qua, 2007-07-11 às 13:29 +0200, Hanno Zulla escreveu:
> 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.
It is the second :) I was in vacations.

> > 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?

Debugging this type of trouble is not always easy, since it is
system-specific, and probably not directly related to cx88 driver, since
cx88 drivers work fine on several configurations. 

So, we need more details about your configuration. You may try also to
use the latest vanilla linux kernel (2.6.22.1). Maybe this might be an
issue already handled.

You can do a "cat /proc/interrupts". This will help to identify the
shared interrupts and if the processors are balancing the IRQ handling. 

There are some tutorials that may help seeking for a bug:
Documentation/BUG-HUNTING

Also, the file /REPORTING-BUGS, at the main tree contains some
orientations on what kind of information can be retrieved for you to
report a bug.

This can also help you to force the handling of an IRQ to an specific
CPU:
Documentation/IRQ-affinity.txt                                                                          

-- 
Cheers,
Mauro