mixed up lines from different channels with 8 ch bt878 card
mixed up lines from different channels with 8 ch bt878 card
I have a 8 channel (with 8 bt878) card with PLX PCI6150 PCI bridge which appears to be from China.
This card worked fine in a linux server with 6 cameras connected with a board with NVIDIA chipset and AMD XP2600.
Now I'm running this card in DualCore system with P35 board and it's running inside a XEN DomU (virtual machine).
The problem is that single lines from channels are sporadic appearing in pictures of other channels. Sometimes only a half, one or two lines, sometimes a half picture.
Since the card has one bt878 for each channel and the lines are from different channels this is not an interlacing problem.
Configuration:
Xen 3.2, kernel 2.6.24-19-xen (DomU + interrupts limited to one core)
ZoneMinder v1.23.2
7 channels: PAL 720x576
1 channel: PAL 288x320
framerate: 3, alarm 5
options bttv gbuffers=32 radio=-1 tuner=4 card=77,77,77,77,77,77,77,77 autoload=0
As far as I know and tried, the valid range for gbuffers is 2-32 and everything above that defaults to something like 2 or 8.
I also tried to increase shared memory with no effects.
I'm not 100% sure, but the problem seems to load/interrupt dependent.
As far as I remember, I had similar problems (but more with hole pictures) on the other system when gbuffers was too small. But there seems to be no way to increase it.
Any ideas ?
This card worked fine in a linux server with 6 cameras connected with a board with NVIDIA chipset and AMD XP2600.
Now I'm running this card in DualCore system with P35 board and it's running inside a XEN DomU (virtual machine).
The problem is that single lines from channels are sporadic appearing in pictures of other channels. Sometimes only a half, one or two lines, sometimes a half picture.
Since the card has one bt878 for each channel and the lines are from different channels this is not an interlacing problem.
Configuration:
Xen 3.2, kernel 2.6.24-19-xen (DomU + interrupts limited to one core)
ZoneMinder v1.23.2
7 channels: PAL 720x576
1 channel: PAL 288x320
framerate: 3, alarm 5
options bttv gbuffers=32 radio=-1 tuner=4 card=77,77,77,77,77,77,77,77 autoload=0
As far as I know and tried, the valid range for gbuffers is 2-32 and everything above that defaults to something like 2 or 8.
I also tried to increase shared memory with no effects.
I'm not 100% sure, but the problem seems to load/interrupt dependent.
As far as I remember, I had similar problems (but more with hole pictures) on the other system when gbuffers was too small. But there seems to be no way to increase it.
Any ideas ?
Last edited by jack on Tue Dec 16, 2008 2:15 pm, edited 1 time in total.
Your options do work, but not better than my old: the problem still exists.
But it really speeds up booting, thanks!
I know now I little more than before:
If I start only the DomU with ZM everything works fine, no image problems.
If I start a second DomU it still works fine, until a certain point. The problems begin, when a software using two other PCI cards (low traffic, but one is polled very often, as far as I know) and the USB controller (don't know exactly, but >10MB/s I guess). Still have to figure out which is the cause exactly, but I guess it's one of the PCI cards.
Even if it is some kind of interrupt/pci problem, I don't really understand how image data could be mixed up between different channels.
Perhaps a bug in the Xen PCI routines? But all other PCI devices seem to have no problems so far.
Some kind of buffer overflow inside the bttv driver (or ZM) due to latency problems?
But it really speeds up booting, thanks!
I know now I little more than before:
If I start only the DomU with ZM everything works fine, no image problems.
If I start a second DomU it still works fine, until a certain point. The problems begin, when a software using two other PCI cards (low traffic, but one is polled very often, as far as I know) and the USB controller (don't know exactly, but >10MB/s I guess). Still have to figure out which is the cause exactly, but I guess it's one of the PCI cards.
Even if it is some kind of interrupt/pci problem, I don't really understand how image data could be mixed up between different channels.
Perhaps a bug in the Xen PCI routines? But all other PCI devices seem to have no problems so far.
Some kind of buffer overflow inside the bttv driver (or ZM) due to latency problems?
cat /proc/interrupts (inside DomU)
I just added a PV-981 16 port PCIe card (bttv0-3), which didn't change anything. Unfortunately I did no cat /proc/interrupts before, but I guess this wouldn't have changed anything, because INT16-19 are only assignable for PCIe devices (?).
At first glance I thought perhaps two channels on the same interrupt are mixed, but they are not:
Bttv7 and btt8 are sometimes mixed e.g..
Sometimes the offset of the inserted data seems to differ so the H/V sync doesn't match. Sometimes the colors of the inserted lines are also not correct, perhaps because of an offset shift too.
Additional options:
xtra = '2 console=xvc0 noirqdebug swiotlb=force iommu=soft"
I've got a lot of other PCI hardware running inside DomUs without any problems, so I guess this is most likely not the problem.
Code: Select all
CPU0
16: 159 Phys-irq-level bttv0
17: 31399 Phys-irq-level bttv1
18: 39229908 Phys-irq-level bttv2
19: 175673 Phys-irq-level bttv3
20: 1704220 Phys-irq-level bttv7, bttv11
21: 7995482 Phys-irq-level bttv6, bttv10
22: 1701471 Phys-irq-level bttv5, bttv9
23: 407392 Phys-irq-level bttv4, bttv8
256: 6532058 Dynamic-irq-level timer0
257: 0 Dynamic-irq-level resched0
258: 0 Dynamic-irq-level callfunc0
259: 694 Dynamic-irq-level xenbus
260: 255 Dynamic-irq-level xencons
261: 19392 Dynamic-irq-level blkif
262: 17 Dynamic-irq-level blkif
263: 23078 Dynamic-irq-level blkif
264: 94971 Dynamic-irq-level eth4
NMI: 0 Non-maskable interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
At first glance I thought perhaps two channels on the same interrupt are mixed, but they are not:
Bttv7 and btt8 are sometimes mixed e.g..
Sometimes the offset of the inserted data seems to differ so the H/V sync doesn't match. Sometimes the colors of the inserted lines are also not correct, perhaps because of an offset shift too.
I excluded all PCI ID in Dom0 (including the corresponding bridge chip ID) and include them in the DomU (pci = ['02:00.0', ...])cordel wrote:How did you configure xen DomU to use the card?
Did you exclude it in Dom0?
Additional options:
xtra = '2 console=xvc0 noirqdebug swiotlb=force iommu=soft"
I've got a lot of other PCI hardware running inside DomUs without any problems, so I guess this is most likely not the problem.
ups...how embarrassing. I edited it quicklycordel wrote:BTW ZoneAlarm is a firewall software, we are ZoneMinder
Changed my configuration to:
- Debian Lenny, kernel 2.6.26-2-xen-amd64
- ZM 1.23.3 (1.24.2 doesn't compile with Lenny's ffmpeg)
- dvb-multiproto v4l drivers (forgot to mention these before)
- Running everything in Dom0, after I thought DomU/shared interrupts could be the cause
-> no change, problem still exist.
Now I found these threads dealing with the same problems:
Movement artifacts
Strange Artifacting
So Xen is not the cause, I guess. Leaves only v4l or ZM....
- Debian Lenny, kernel 2.6.26-2-xen-amd64
- ZM 1.23.3 (1.24.2 doesn't compile with Lenny's ffmpeg)
- dvb-multiproto v4l drivers (forgot to mention these before)
- Running everything in Dom0, after I thought DomU/shared interrupts could be the cause
-> no change, problem still exist.
Now I found these threads dealing with the same problems:
Movement artifacts
Strange Artifacting
So Xen is not the cause, I guess. Leaves only v4l or ZM....
With my current setup I do have some new problems, which doesn't exist before:
Every 52 seconds, I got timeouts for every channel on both bt878 cards (one at the time, not all together):
I'm not sure whether it's linked to the image distortion problem. Since I hadn't these log messages before, I guess not.
Any ideas?
Every 52 seconds, I got timeouts for every channel on both bt878 cards (one at the time, not all together):
Code: Select all
kernel: [88361.070183] bttv8: timeout: drop=10498 irq=4465235/8687415, risc=afec204c, bits: HSYNC OFLOW
Any ideas?
Just like to thank Lee Sharp for his help
this fixed it for me
Billy
Code: Select all
options bttv gbuffers=16 radio=-1 tuner=4 card=102,102,102,102,102,102,102,102
Billy