public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: David Engel <david@istwok.net>
To: Steven Toth <stoth@linuxtv.org>
Cc: linux-media@vger.kernel.org, V4L <video4linux-list@redhat.com>
Subject: Re: PVR x50 corrupts ATSC 115 streams
Date: Tue, 17 Feb 2009 14:17:40 -0600	[thread overview]
Message-ID: <20090217201740.GA9385@opus.istwok.net> (raw)
In-Reply-To: <499AE054.6020608@linuxtv.org>

On Tue, Feb 17, 2009 at 11:05:40AM -0500, Steven Toth wrote:
>> Does anyone know what might be going on?  These very same tuner cards
>> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
>> motherboard) for close to two years.
>
> Determine whether this is an RF issue, or a DMA corruption issue:

Ahh, I didn't even think of RF.  I didn't have any RF problems in the
old system (that I know of) so that didn't even cross my mind.  I
actually was, and still am, more afraid of DMA issues, though.

> 1. Check the RF SNR of the digital cards using femon, anything odd going 
> on when the PVR250 is running? Does it fall out of lock or SNR dip 
> dangerously low, bursts of BER's?

Here are some 10 second captures from femon.  Card1 and Card2 are ATSC
115s.  Card4 and Card5 are PVR x50s.

Card1 recording by itself:

status SCVYL | signal fe90 | snr e4dc | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e682 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e624 | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e598 | ber 00000140 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e654 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e6b2 | ber 00000090 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e654 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK

Card1 and Card4 recording:

status SCVYL | signal fe80 | snr e5c6 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e682 | ber 00000100 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e53a | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e568 | ber 00000130 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e624 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e654 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e6b2 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 00000028 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e624 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK

Card1 and Card5 recording:

status SCVYL | signal fe40 | snr e624 | ber 00000120 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e654 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e598 | ber 00000238 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e682 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal feb0 | snr e654 | ber 00000068 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e654 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal feb0 | snr e6e0 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e4dc | ber 00000060 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e44e | ber 00000058 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e5c6 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK

Card2 recording by itself:

status SCVYL | signal fe20 | snr e53a | ber 00000130 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e53a | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe30 | snr e3c0 | ber 00000128 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e3c0 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e568 | ber 00000060 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe00 | snr e4dc | ber 00000058 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e53a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fde0 | snr e4dc | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e568 | ber 00000168 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fdf0 | snr e53a | ber 000001a0 | unc 00000000 | FE_HAS_LOCK

Card2 and Card4 recording:

status SCVYL | signal fe40 | snr e4ac | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e624 | ber 000001b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e598 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e5c6 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e53a | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e50a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e50a | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe30 | snr e5f6 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e568 | ber 00000180 | unc 00000000 | FE_HAS_LOCK

Card2 and Card5 recording

status SCVYL | signal fe70 | snr e4ac | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e598 | ber 00000190 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e598 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e5c6 | ber 00000008 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e568 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e5c6 | ber 00000178 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e53a | ber 00000120 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e50a | ber 00000168 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e5c6 | ber 000000f8 | unc 00000000 | FE_HAS_LOCK

I don't see anything significant there.

> 2. Move the two cards as far apart as possible in the slots in the system 
> and repeat the test above, any better?
>
> What happens?

This will require rmoving cards.  The old system had 5 PCI slots and I
had a small ethernet NIC between the pair of 115s and x50s.  The new
system only has 4 PCI slots so both pairs are in adjacent slots.  I'll
try pulling the x50s one at a time this evening when I get home.

David
-- 
David Engel
david@istwok.net

  reply	other threads:[~2009-02-17 20:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17 15:53 PVR x50 corrupts ATSC 115 streams David Engel
2009-02-17 16:05 ` Steven Toth
2009-02-17 20:17   ` David Engel [this message]
2009-02-17 20:29     ` Steven Toth
2009-02-17 20:56       ` David Engel
2009-02-17 21:05         ` Devin Heitmueller
2009-02-17 22:29           ` Steven Toth
2009-02-17 22:38             ` Devin Heitmueller
2009-02-18 15:16               ` Steven Toth
2009-02-19  2:11                 ` CityK
2009-02-19 15:26                   ` Steven Toth
2009-02-18  5:19       ` David Engel
2009-02-18  8:25         ` Rudy Zijlstra
2009-02-18 15:29           ` David Engel
2009-02-18 14:56         ` Steven Toth
2009-02-18 15:34           ` David Engel
2009-02-19 16:28             ` David Engel
2009-02-19 16:44               ` Steven Toth
2009-02-22 19:35               ` CityK
2009-02-23 18:39                 ` David Engel
2009-02-23 19:06                   ` Steven Toth
2009-02-23 20:10                     ` David Engel
2009-02-23 21:53                       ` Steven Toth
2009-02-23 22:03                         ` Devin Heitmueller
2009-02-23 22:48                           ` David Engel
2009-02-23 22:58                             ` Devin Heitmueller
2009-02-24  1:38                               ` pat-lkml
2009-02-24 16:40                               ` David Engel
2009-02-24  0:05                       ` Andy Walls
2009-08-07  2:50 ` David Engel
  -- strict thread matches above, loose matches on Subject: below --
2009-02-18 12:41 Andreas
2009-02-18 15:39 ` David Engel
2009-02-19  3:37 ` CityK
2009-02-19 13:30   ` Andreas

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=20090217201740.GA9385@opus.istwok.net \
    --to=david@istwok.net \
    --cc=linux-media@vger.kernel.org \
    --cc=stoth@linuxtv.org \
    --cc=video4linux-list@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox