On Tue, 11 Nov 2014 19:05:37 +0100
Hans Verkuil hverk...@xs4all.nl wrote:
On 11/11/2014 06:46 PM, Andrey Utkin wrote:
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
On Sat, 15 Nov 2014 21:42:05 +0100
khal...@piap.pl (Krzysztof Hałasa) wrote:
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it
turns out not to work
Thanks to all for the great help so far, but I've got another issue
with upstream driver.
In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
out not to work correctly: the frame is offset, so that in the bottom
Hi Andrey,
On 11/15/2014 02:48 PM, Andrey Utkin wrote:
Thanks to all for the great help so far, but I've got another issue
with upstream driver.
In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
out not to
On Sat, Nov 15, 2014 at 6:08 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Andrey,
On 11/15/2014 02:48 PM, Andrey Utkin wrote:
Thanks to all for the great help so far, but I've got another issue
with upstream driver.
In upstream there's no more module parameter for video standard
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
out not to work correctly: the frame is offset, so that in the bottom
there's black horizontal bar.
The
On Sun, Nov 16, 2014 at 12:42 AM, Krzysztof Hałasa khal...@piap.pl wrote:
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
In upstream there's no more module parameter for video standard
(NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
out not to work correctly: the
Andrey Utkin andrey.ut...@corp.bluecherry.net writes:
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
2014-11-14 15:00 GMT+04:00 Krzysztof Hałasa khal...@piap.pl:
There is a race condition in the IRQ handler, at least in 3.17.
I don't know if it's related, will post a patch.
Thank you for your interest.
Looking forward for your patch. If you don't have time, please just
say what races with
On Tue, Nov 11, 2014 at 10:16 PM, Andrey Utkin
andrey.ut...@corp.bluecherry.net wrote:
On Tue, Nov 11, 2014 at 8:05 PM, Hans Verkuil hverk...@xs4all.nl wrote:
I would first try to exclude hardware issues: since you say it is always
the same card, try either replacing it or swapping it with
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
On 11/11/2014 06:46 PM, Andrey Utkin wrote:
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
On Tue, Nov 11, 2014 at 8:05 PM, Hans Verkuil hverk...@xs4all.nl wrote:
I would first try to exclude hardware issues: since you say it is always
the same card, try either replacing it or swapping it with another solo
card and see if the problem follows the card or not. If it does, then it
is
13 matches
Mail list logo
