[CentOS] Very odd issue w/ a CentOS 6 system

Wed Mar 23 20:27:20 UTC 2016
Phil Wyett <philwyett at irregulars-engineering.com>

On Wed, 2016-03-23 at 15:45 -0400, m.roth at 5-cent.us wrote:
> Phil Wyett wrote:
> > On Wed, 2016-03-23 at 15:16 -0400, m.roth at 5-cent.us wrote:
> >> Phil Wyett wrote:
> >> > On Wed, 2016-03-23 at 10:26 -0400, m.roth at 5-cent.us wrote:
> >> <snip>
> >> >> >
> >> >> > What is the make/model of the card?
> >> >> lspci says:
> >> >> Brooktree Corporation Bt878 Audio Capture (rev 11)
> >> >> >
> >> >> > Are you supplying options when loading the bttv module?
> >> >>
> >> >> On and off, I've been googling to find if there's something I can
> >> tell
> >> >> it,or the kernel on boot. Currently, I have, in /etc/modprobe.d/bttv:
> >> >> options i2c-algo-bit bit_test=1
> >> >> options bttv gbuffers=16 card=98,98,98,98,98,98,98,98
> >> >> radio=0,0,0,0,0,0,0,0 tuner=4,4,4,4,4,4,4,4 chroma_agc=1 combfilter=2
> >> >> full_luma_range=1 coring=1
> >> >
> >> > The options line 1 is used widely and only worth changing if all else
> >> > fails.
> >> >
> >> > The second options line option of combfilter by docs indicate there is
> >> > no 2 option and is enabled by default, so you can remove that option
> >> to
> >> > test.
> >> >
> >> > I would enable two possible compatibility options and see if that
> >> helps.
> >> >
> >> > triton1=0/1 - for Triton1 (+others) compatibility.
> >> >
> >> > vsfx=0/1 - yet another chipset bug compatibility bit
> >> >
> >> > The triton1 insmod option sets the EN_TBFX bit in the control
> >> register.
> >> > The vsfx insmod option does the same for EN_VSFX bit. If you have
> >> > stability problems you can try if one of these options makes your box
> >> > work solid.
> >> >
> >> > Source:
> >> http://xawdecode.sourceforge.net/aideUS/htmlpage/BTTV-param.htm
> >> >
> >>
> >> Ok, I've been doing some research, partly refreshing my memory, since we
> >> bought these 2-3 years ago. As you note, above, it *says* it's an iTuner
> >> Spectra8; *however*, when I look at bttv-cards.c, what I see is that
> >> *it*
> >> thinks that such a card has *one* video and one audio. In fact, this is
> >> a
> >> Bt878, and it has *four* inputs for each, with four chips on the card,
> >> one
> >> for each channel. The nearest thing to it *appears* to be a Provideo
> >> PV150, card=98 (which is why I have that card= line in the bttv.conf).
> >>
> >> Now that I'm thinking about it, and while googling, I looked for the
> >> provideo 150, and what *should* have been the link took me to one for a
> >> provideo 950, with *16* inputs. Does anyone have opinions on:
> >>   1. should I change the card-, radio=, and tuner= to only have four,
> >> instead of 8, values? I realize that it multiplexes for 8, but....
> >>   2. What is "coring"?
> >>
> >>        mark
> >
> > Hi Mark,
> >
> > It did specify spectra 8 in your lspci output. Below is product page.
> >
> > http://www.ituner.com/spectra.htm
> >
> > In my research I did find this related page.
> >
> > http://www.linuxconsulting.ro/spectra8/
> >
> > This does state that with latest internal driver, it is detected and
> > works as the ProVision 150. The card=98,... is correct.
> >
> > The matter of reducing all the settings to 4 rather than 8 may help.
> >
> > coring is a luma setting. See:
> >
> > https://www.linuxtv.org/wiki/index.php/Bttv#insmod_Options
> >
> > Not sure and someone else maybe can shed better light on the setting. By
> > default it is disabled and I would tend to think it can be removed.
> >
> Any thoughts on the number of buffers?
> 
>         mark

Hi Mark,

You have the setting of 16 which maybe correct for how many feeds you
are taking/processing. If less I maybe tempted to drop it to the default
8. If the device is running as close to or at default and no hickups -
all the better. :-)

Regards

Phil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos/attachments/20160323/1db00a13/attachment-0005.sig>