At Bluecherry, we have issues with servers which have 3 solo6110 cards
(and cards have up to 16 analog video cameras connected to them, and
being actively read).
This is a kernel which I tested with such a server last time. It is
based on linux-next of October, 31, with few patches of mine (all are
in review for upstream).
https://github.com/krieger-od/linux/ . The HEAD commit is
949e18db86ebf45acab91d188b247abd40b6e2a1 at the moment.

The problem is the following: after ~1 hour of uptime with working
application reading the streams, one card (the same one every time)
stops producing interrupts (counter in /proc/interrupts freezes), and
all threads reading from that card hang forever in
ioctl(VIDIOC_DQBUF). The application uses libavformat (ffmpeg) API to
read the corresponding /dev/videoX devices of H264 encoders.
Application restart doesn't help, just interrupt counter increases by
64. To help that, we need reboot or programmatic PCI device reset by
"echo 1 > /sys/bus/pci/devices/0000\:03\:05.0/reset", which requires
unloading app and driver and is not a solution obviously.

We had this issue for a long time, even before we used libavformat for
reading from such sources.
A few days ago, we had standalone ffmpeg processes working stable for
several days. The kernel was 3.17, the only probably-relevant change
in code over the above mentioned revision is an additional bool
variable set in solo_enc_v4l2_isr() and checked in solo_ring_thread()
to figure out whether to do or skip solo_handle_ring(). The variable
was guarded with spin_lock_irqsave(). I am not sure if it makes any
difference, will try it again eventually.

Any thoughts, can it be a bug in driver code causing that (please
point which areas of code to review/fix)? Or is that desperate
hardware issue? How to figure out for sure whether it is the former or
the latter?

-- 
Bluecherry developer.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to