Mailing List Archive: system lockups with ivtv and bttv

system lockups with ivtv and bttv

Apr 29, 2009, 9:20 PM

Post #1 of 3 (2710 views)

I'm running centos 5.2 2.6.18-128.1.1.el5, mythtv mythtv-0.21-203.el5

I'm getting system lockups that appear to be the interaction of my
two video capture cards. I'm running a PVR-350 and a LMLBT44. when
I'm running mythtv AND zoneminder, I get errors along the lines of:

Apr 23 21:44:59 glutton kernel: bttv0: OCERR @ 7a807014,bits: HSYNC
OFLOW FBUS FDSR OCERR* (which seem to be tied to video capture from
the PVR-350.

In /proc/interrupts I see:

0: 306846 0 IO-APIC-edge timer
1: 10 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 471 0 IO-APIC-edge i8042
169: 1986 14619 IO-APIC-level ehci_hcd:usb1, eth0
177: 551 0 IO-APIC-level ohci_hcd:usb2, HDA Intel
185: 22482 33199 IO-APIC-level sata_nv
193: 419 15 IO-APIC-level sata_nv
201: 9 0 IO-APIC-level bttv0
209: 76360 84342 IO-APIC-level bttv1, ivtv0
217: 4 0 IO-APIC-level bttv2
225: 1 0 IO-APIC-level bttv3
NMI: 163 103
LOC: 306690 306645

Is it possibly bad that one of the channels of the lmlbt44 and the
ivtv0 (pvr-350) are on the same interrupt (and thus acusing lockups)?
I've dabbled to try to make them not use the same IRQ or change how
they load, but it doesn't seem to change anything or fix it.

current modprobe.conf:
alias eth0 forcedeth
alias scsi_hostadapter sata_nv
alias scsi_hostadapter1 usb-storage
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || :
; }; /sbin/modprobe -r --ignore-remove snd-hda-intel

alias char-major-81 videodev
alias char-major-81-0 ivtv
alias char-major-81-1 bttv
alias char-major-81-2 bttv
alias char-major-81-3 bttv
alias char-major-81-4 bttv

options ivtv enc_mpg_buffers=16 dec_mpg_buffers=4

options bttv card=118,118,118,118

install bttv /sbin/modprobe ivtv; /sbin/modprobe --ignore-install bttv

options ivtv-fb osd_compat=1

install ivtv /sbin/modprobe --ignore-install ivtv; /sbin/modprobe ivtv-fb

# for lircd
alias char-major-61 lirc_i2c
install lirc_i2c /sbin/modprobe ivtv; /sbin/modprobe --ignore-install lirc_i2c

alias snd-card-0 snd-hda-intel
options snd-card-0 index=0

Any ideas what could be making the system lock? Things seem
completely stable when zonemidner isn't running, and seem to be
(still not 100% confident) as stable with ZM but not myth. It's the
two together that look to be killing me.

Rick

Rick Steeves
http://www.sinister.net

"Life is like a sausage: The more you pack into it, the longer it gets"

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: system lockups with ivtv and bttv [ In reply to ]

awalls at radix

Apr 30, 2009, 5:15 PM

Post #2 of 3 (2637 views)

Permalink

On Thu, 2009-04-30 at 00:20 -0400, ivtvdriver@corwyn.net wrote:
>
> I'm running centos 5.2 2.6.18-128.1.1.el5, mythtv mythtv-0.21-203.el5
>
> I'm getting system lockups that appear to be the interaction of my
> two video capture cards.

Can you be more specific? Does the lockup leave an Ooops or Bug
in /var/log/messages you can read later? Is an Oops on panic dumped to
the screen, and if so, can you transcribe all the info? When the lockup
happens can you do a VT switch (Ctrl-Alt-F2) and log in to look at the
logs or dmesg?

> I'm running a PVR-350 and a LMLBT44. when
> I'm running mythtv AND zoneminder, I get errors along the lines of:
>
> Apr 23 21:44:59 glutton kernel: bttv0: OCERR @ 7a807014,bits: HSYNC
> OFLOW FBUS FDSR OCERR* (which seem to be tied to video capture from
> the PVR-350.

Well, no, that would be the bttv driver as indicated by the "bttv0:" in
the message.

"OCERR" is a "RISC instruction error" meaning the BT878 chip tried to
execute a garbage instruction. See page 130 of:

http://www.datasheetarchive.com/pdf-datasheets/Datasheets-10/DSA-187671.pdf

You can load the bttv module with the bttv_debug=1 option (or set the
option in /etc/modprobe.conf) to get a more detailed dump of the bad
instructions.

This sort of thing is likely caused by PCI bus errors when communicating
with the BT878 chip in question. A busy PCI bus and poor connections
could cause errors. It could also be just a failing BT878 chip.

The best course of action for you, since from past experience I know the
BT878 seems a little sensitive to the quality of PCI bus signal
voltages, is to remove all your PCI cards, blow the dust out of the
slots and reseat all your PCI cards. The PCI bus uses reflected voltage
waves to get the proper voltage levels, so it is not sufficient to clean
the dust/crud out of only the slot with the BT878.

> In /proc/interrupts I see:
>
> 0: 306846 0 IO-APIC-edge timer
> 1: 10 0 IO-APIC-edge i8042
> 8: 1 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-level acpi
> 12: 471 0 IO-APIC-edge i8042
> 169: 1986 14619 IO-APIC-level ehci_hcd:usb1, eth0
> 177: 551 0 IO-APIC-level ohci_hcd:usb2, HDA Intel
> 185: 22482 33199 IO-APIC-level sata_nv
> 193: 419 15 IO-APIC-level sata_nv
> 201: 9 0 IO-APIC-level bttv0
> 209: 76360 84342 IO-APIC-level bttv1, ivtv0
> 217: 4 0 IO-APIC-level bttv2
> 225: 1 0 IO-APIC-level bttv3
> NMI: 163 103
> LOC: 306690 306645
>
> Is it possibly bad that one of the channels of the lmlbt44 and the
> ivtv0 (pvr-350) are on the same interrupt (and thus acusing lockups)?

The error is for bttv0 which doesn't share an interrupt with ivtv0. So,
no, interrupt service shouldn't be the problem here. It doesn't look
like bttv0, bttv2, and bttv3 had been doing much work at all when you
looked at the interrupt counts.

> I've dabbled to try to make them not use the same IRQ or change how
> they load, but it doesn't seem to change anything or fix it.

It probably wouldn't matter.

> Any ideas what could be making the system lock? Things seem
> completely stable when zonemidner isn't running, and seem to be
> (still not 100% confident) as stable with ZM but not myth. It's the
> two together that look to be killing me.

It sure looks like a PCI bus error on writing RISC instructions to the
BT878 for it to execute. I assume ZM only looks at the bttvN devices
and myth does not, so it would make sense to have no bttv related
problems when ZM was not running.

Regards,
Andy

PS. The Bt879 data sheet I pointed to is interesting to me for 2
reasons:

1. It's got a Rockwell logo in the footer indicating it's from the time
when Conexant was still the (switching?) circuits part of
Rockwell-Collins and hadn't been spun off yet, but a time after they had
bought BrookTree or BrookTree's intellectual property.

2. It's amazing how much of the Bt879 ended up inside the CX25840/1/2/3
video digitizer/decoder that's on many PVR-150 boards.

> Rick
>
>
> Rick Steeves
> http://www.sinister.net

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: system lockups with ivtv and bttv [ In reply to ]

ivtvdriver at corwyn

May 1, 2009, 8:48 PM

Post #3 of 3 (2615 views)

Permalink

At 08:15 PM 4/30/2009, Andy Walls wrote:
>On Thu, 2009-04-30 at 00:20 -0400, ivtvdriver@corwyn.net wrote:
> >
> > I'm running centos 5.2 2.6.18-128.1.1.el5, mythtv mythtv-0.21-203.el5
> >
> > I'm getting system lockups that appear to be the interaction of my
> > two video capture cards.
>
>Can you be more specific? Does the lockup leave an Ooops or Bug
>in /var/log/messages you can read later?

when the system locks up I get no signal on the monitor, and thus
can't see what happened. I've left a SSH session open to
/var/log/messages, but there's nothing there except for errors like below:
Apr 23 21:44:59 glutton kernel: bttv0: OCERR @ 7a807014,bits: HSYNC
OFLOW FBUS FDSR OCERR*

>Is an Oops on panic dumped to
>the screen, and if so, can you transcribe all the info? When the lockup
>happens can you do a VT switch (Ctrl-Alt-F2) and log in to look at the
>logs or dmesg?

Nope, I get no response from the system at all. The monitor has no
signal, and I can't get to anything. Keyboard numlock doesn't respond.

> I'm running a PVR-350 and a LMLBT44. when
> > I'm running mythtv AND zoneminder, I get errors along the lines of:
> >
> > Apr 23 21:44:59 glutton kernel: bttv0: OCERR @ 7a807014,bits: HSYNC
> > OFLOW FBUS FDSR OCERR* (which seem to be tied to video capture from
> > the PVR-350.
>
>Well, no, that would be the bttv driver as indicated by the "bttv0:" in
>the message.

Perhaps, but it seems like I get that error message when the
PVR/Mythtv is recording when ZM is running. I suppose it could be
from ZM (capturing when I don't expect it to be), but it's always
seemed to correlate more to mythtv running.

>The best course of action for you, since from past experience I know the
>BT878 seems a little sensitive to the quality of PCI bus signal
>voltages, is to remove all your PCI cards, blow the dust out of the
>slots and reseat all your PCI cards. The PCI bus uses reflected voltage
>waves to get the proper voltage levels, so it is not sufficient to clean
>the dust/crud out of only the slot with the BT878.

Could it be that easy? Ok, I'll try that. thanks!

rick
PS The system has only two pc slots, and I've been reluctant to
switch the cards because hte ventilation is "Better" with the cards
in 1,2 instead of 2,1. could switching pci slots be a valid way to fix?

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users