Streams freezing (no new encoded frames up to reboot)

[ghost]

This is known to reproduce with 2.4.9-3, 2.4.9-4 and 2.4.8-8 with solo6110 16-port cards. The host i have seen with this issue had IRQ # 16 shared between solo6x10-edge driver and "ehci_hcd:usb1", according to /proc/interrupts . It had 4-cores Intel CPU @3.5 GHz. Module reloading doesn't help the bug, only machine reboot helps.
The manifestation of issue: after some time of normal functioning (sometimes several minutes, sometimes approx. an hour) no new frames are produced by opened V4L2 descriptors.
From extensive printk-ing of driver code, i have figured out that no new interrupts were processed with solo_isr().
I have tried some random changes, like

• omitting modification of irq mask in "ring" thread routine

  solo6x10/solo6x10-v4l2-enc.c

  Line 798 in 1942060

  solo_irq_off(solo_dev, SOLO_IRQ_ENCODER);

  ,
• disabling this check which i don't understand

  solo6x10/solo6x10-v4l2-enc.c

  Line 741 in 1942060

  if (cur_q == solo_dev->enc_idx)

  .

That haven't eliminate the issue. But i believe the first change is positive, and the second change has a result of driver proceeding handling other interrupts (not of h264 encoder, but P2M), although that resulted in strange effects - e.g. stale frame was retransmitted.

I was unable to reproduce this issue with 8-port solo6110 card. My host also doesn't make solo6x10-edge's IRQ number shared with anything else.

[ismaell]

The second check is about making sure you don't try to handle things that you have already handled in a previous run. I've not run into this one before, but sound like we have to rethink the way we do interrupt handling...

[ismaell]

I have an idea of what might be happening...

[ghost]

sound like we have to rethink the way we do interrupt handling...

I have an idea of what might be happening...

@ismaell, you get available so rarely and for so little time... Could you at last open your ideas, so that we could work on issues and not stay blocked because of your absence?

[ghost]

This feature was reported to be NOT reproducing with kernel v3.11.0 + solo6x10-edge v2.4.9-4 (after having that issue with kernel v3.11.0 + solo6x10-edge v2.4.8-8; kernel v3.2.0-6x + solo6x10-edge v2.4.9-4 installation with this issue was also encountered).