From: Ninja <Ninja15@gmx.de>
To: linux-media <linux-media@vger.kernel.org>
Subject: Re: Multiple Mantis devices gives me glitches
Date: Tue, 13 Dec 2011 08:48:33 +0100 [thread overview]
Message-ID: <4EE70351.8030200@gmx.de> (raw)
In-Reply-To: <4EE682B3.4090301@tyldum.com>
> Hello,
>
> I have three Cinergy C (DVB-C cards) like this:
> 05:04.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI
> Bridge Controller [Ver 1.0] (rev 01)
> Subsystem: TERRATEC Electronic GmbH Device 1178
> Flags: bus master, medium devsel, latency 128, IRQ 20
> Memory at fdcfe000 (32-bit, prefetchable) [size=4K]
> Kernel driver in use: Mantis
> Kernel modules: mantis
>
> Kernel: 2.6.38-13-generic-pae (Ubuntu Natty stock)
> Motherboard: P43-ES3G
> CPU: Intel(R) Core(TM)2 Quad CPU Q8400
>
> At some point i started having glitches (I would from time to time get an
> 'old' frame displayed and sometimes audio noise when this happened). I tried
> pretty much every trick I could find:
> * CPU affinity
> * Dedicated IRQ for each card (only shared with USB, which has no units
> attached)
> * Various process priorities (also for the kdvb-processes)
> * pci latency (from 0x20 to 0xff)
>
> I have quite decent results when I only have 2 DVB cards present, and the
> results became even better when running the irqbalancer-dæmon as well.
> The glitches are not completely gone, but much more manageble now.
>
> So the problem seems to be caused by too many interrupts for my system to
> handle, however this is where I am in over my head.
>
> I know 2.6.38 isn't the freshest brew, but I could not find any changes to
> the driver since then that seemed relevant (which could just be my lack of
> source-fu).
>
> So, any ideas on how to improve the performance? I am suffering from some
> hardware incompatibility or is the driver this resource hungry?
Hi,
I noticed some SMP problems with the mantis driver as well (see my post
"Mantis CAM not SMP safe / Activating CAM on Technisat Skystar HD2
(DVB-S2)").
One workaround for me is to limit the CPU to one core (to be sure
disable the hyperthreading cores as well). That can be done via BIOS
*or* adding maxcpus=1 as kernel parameter *or* you can disable the cores
one by one via "|echo 0 > /sys/devices/system/cpu/cpuX/online|" where X
is the core to disable. Since you need to be root for this, I did "sudo
su" first.
But of course our problems might be completely unrelated and limiting to
one core won't change a thing ;)
Manuel
next prev parent reply other threads:[~2011-12-13 7:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 22:39 Multiple Mantis devices gives me glitches Vidar Tyldum
2011-12-13 7:48 ` Ninja [this message]
2011-12-13 16:55 ` Vidar Tyldum
-- strict thread matches above, loose matches on Subject: below --
2011-12-13 7:31 Marko Ristola
2011-12-13 13:55 ` Vidar Tyldum
2011-12-13 18:11 ` Vidar Tyldum
2011-12-13 21:56 ` Marko Ristola
2011-12-14 18:23 ` Vidar Tyldum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE70351.8030200@gmx.de \
--to=ninja15@gmx.de \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.