One debugging note - make sure you only have
one version of bttv.o, btaudio.o and videodev.o
under /lib/modules/`uname -r`
find /lib/modules/`uname -r` -name bt* ls -l \{\} \;
I've mistakenly tested a few times with old
versions loading because the install process
doesn't automatically remove them and modprobe
just loads the first found, not necessarily
the newest. btaudio did this for a long time,
now the new bttv load puts 0.8 in a later
directory than the kernel's 0.7 module.
(Gerd, should this be fixed in the install script,
perhaps something like:
MODDIR="/lib/modules/`uname -r`/kernel/drivers"
OLDMODS="sound/btaudio.o media/video/bttv.o media/video/videodev.o"
for file in $OLDMODS; do
if [ -e $MODDIR/$file ]; then
mv -f $MODDIR/$file $MODDIR/$file.old
fi
done
Jon Hittner wrote:
On Wednesday 21 August 2002 04:24 am, Gerd Knorr wrote:
1- After running for several hours the machine will reboot itself (this
machine is NOT set to reboot on panics). This problem seems to happen
with any version of bttv after 0.8.33, but ive never seen it happen with
a prior version.
What means "seems to happen with any version of bttv"? There are a few
known buggy ones between 0.8.33 + 0.8.45 (0.8.34+5 for example, see the
changelog). Which versions exactly did you test? Which kernel? Please
don't switch *both* kernel+bttv versions, better use the old 2.4.17 with
current bttv drivers for debugging this one.
well, I started seeing this happen with 0.8.34 on the same kernel version that
I was running 0.8.33 with no problems(2.4.17). Since that time ive
downloaded new versions every month or so and tried them both on the same
kernel version and newer kernels, having the same problem. I cant recall
exactly which versions ive tried, but there where quite a few. Ive also run
0.8.33 on newer kernels with no problem.
Sometimes there is no messages on the console and sometimes there
are messages like the following:
btaudio: buffer overrun
OFLOW HLOCK VPRES RISCI
bttv2: timeout: risc=065e201c, bits: VSYNC HSYNC OFLOW HLOCK VPRES RISCI
<6>bttv1: timeout: risc=0663201c, bits: VSYNC HSYNC OFLOW HLOCK VPRES
RISCI bttv0: timeout: risc=066d101c, bits: VSYNC HSYNC OFLOW HLOCK VPRES
RISCI
Hmm, multiple bttv cards running in timeouts at the same time. Looks
like some problem with the PCI bus ...
Does this happen without btaudio too?
no, not that I see. Running with all debuging that I can find turned on, all
I see are btaudio: buffer overrun. here is a little more logging of what it
looks like right before a crash:
Aug 19 19:32:57 test1 kernel: *<7>bttv3: irq loop=0 fc=983926 riscs=1,
riscc=023aa01c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv3: irq loop=1 fc=983927 riscs=1,
riscc=023aa01c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv4: irq loop=0 fc=983815 riscs=1,
riscc=07c6a53c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv0: irq loop=0 fc=984834 riscs=1,
riscc=065ce1d4, bits: VSYNC* HSYNC OFLOW RISCI*
Aug 19 19:32:57 test1 kernel: bttv: irq odd=c57696b4 even=c57696b4
screen=00000000 vbi=00000000
Aug 19 19:32:57 test1 kernel: bttv2: irq loop=0 fc=141287 riscs=1,
riscc=00b715dc, bits: VSYNC* HSYNC OFLOW RISCI*
Aug 19 19:32:57 test1 kernel: bttv: irq odd=c7356ad4 even=c7356ad4
screen=00000000 vbi=00000000
Aug 19 19:32:57 test1 kernel: HSYNC<7>bttv3: irq loop=0 fc=983928 riscs=1,
riscc=023aa01c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv3: irq loop=1 fc=983929 riscs=1,
riscc=023aa01c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv4: irq loop=0 fc=983816 riscs=1,
riscc=07c6a53c, bits: VSYNC* HSYNC OFLOW
Aug 19 19:32:57 test1 kernel: bttv0: irq loop=0 fc=984835 riscs=1,
riscc=04cca19c, bits: VSYNC* HSYNC OFLOW RISCI*
Aug 19 19:32:57 test1 kernel: bttv: irq odd=c57695ac even=c57695ac
screen=00000000 vbi=00000000
Aug 19 19:32:57 test1 kernel: bttv2: irq loop=0 fc=141288 riscs=1,
riscc=0082c59c, bits: VSYNC* HSYNC OFLOW RISCI*
Aug 19 19:32:57 test1 kernel: bttv: irq odd=c7356bdc even=c7356bdc
screen=00000000 vbi=00000000
2-When unloading the bttv modules I sometimes get the following panic.
Ive included ksymoops from 2 occurences below, this is very easy to
reproduce, so if you want more info I would be happy to send it:
Yes: How exactly this can be reproduced? I havn't seen rmmod oopses for
a long time.
This is strange, but yesterday I was able to reproduce this with a script that
basicly did:
killall `pidof mp1e`
rmmod bttv btaudio tuner msp3400 video-buf
and it would crash almost everytime time as long as the machine was running
for a few minutes atleast, today when trying to troubleshoot I cant get this
crash to happen. Could it have anything to do with the type of video im
working with? I will keep trying to duplicate this problems again.
Gerd
_______________________________________________
Video4linux-list mailing list
Video4linux-list@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/video4linux-list
--
Bill Eldridge
Radio Free Asia
bill@xxxxxxx
