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
|
solo_irq_off(solo_dev, SOLO_IRQ_ENCODER); |
,
- disabling this check which i don't understand
|
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.
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
solo6x10/solo6x10-v4l2-enc.c
Line 798 in 1942060
solo6x10/solo6x10-v4l2-enc.c
Line 741 in 1942060
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.