Hi Leandro There are no crash oops available, as this is a memory corruption that occurs. The effects differ strongly each time. In most cases the system just stops (as the cpu has run over some corrupted code). In some rare cases one can see strange program behaviour, e.g. the sound library libasound.so responded with a symbol not found error (in this case clearing the kernel cache reloaded the uncorrupted libasound code into memory). After a couple of weeks of tests, I found that this memory corruption only occurs if: - data from the bttv device is directly displayed on the video screen using xv hardware acceleration on an geode lx system It does NOT occur if: - data from the bttv driver is displayed on the video screen using NO hardware acceleration (x11) - data from the bttv driver is transferred first to the hard disk and then (in a second) step displayed on the video screen using xv hardware acceleration - data from the bttv driver is directly displayed on the video screen using xv hardware acceleration, but on an intel based system (also faster, more memory) - data from a NON bttv based video card (em28xx, tw68) is directly displayed on the video screen using xv hardware acceleration on the geode lx system So, that seems to be a strange interaction of the bttv driver with the geode lx video driver. I am pretty sure nobody will easily find this one. :-( So, we finally switched to a TW6805 based card using the new tw68 driver from William Brack. Thanks for your consideration and best regards Michael Am Montag, 22. Februar 2010 schrieb leandro Costantino: > Hi Michael, > > could you attach any of the crash oops? That would be of help for bttv > developers here. > > Best Regards > > On Wed, Feb 3, 2010 at 2:10 PM, Michael <auslands-kv@xxxxxx> wrote: > > Hello > > > > We use embedded devices running debian lenny (kernel 2.6.31.4 with bttv > > driver 0.9.18) to monitor an incoming video signal digitized via a video > > grabber. The /dev/video0 device is opened and closed several hundred > > times a > > day. > > > > We used to use an em28xx USB based grabber but now switched to an > > Mini-PCI bttv card (Commel MP-878) due to USB issues. > > > > With the bttv card we experience different crashes, usually after a > > couple of days, while the systems using the em28xx show none even after > > an extended > > time frame. > > > > The crashes differ strongly. We saw system freezes and also a very > > interesting problem, where libasound.so.2 couldn't find some symbol. We > > debugged the latter case, finding that all applications using > > libasound.so.2 > > no longer worked, giving the same error of a symbol not found. The > > problem could be remedied by flushing the kernel cashes (echo 1 > > > /proc/sys/vm/drop_caches). > > > > So it might be possible that the systems using the bttv Mini-PCI card > > corrupt memory after a couple of days, resulting into different failures. > > > > To examine the crashes I wrote a small test program, which simply opens > > and closes the bttv video device repeatedly: > > > > #!/bin/bash > > > > count=0 > > while [ 1 == 1 ] > > do > > ((count++)) > > date; echo "COUNT = " $count > > mplayer -frames 10 -fs -vo xv tv:// -tv norm=pal:input=1 > > > /dev/null sleep 0.1 > > done > > > > With this program I experienced full hard crashes after 85 counts, 760 > > counts and 3870 counts today, comprising between a couple of minutes and > > hours. In all cases the hardware watchdog timer resetted the system. > > > > The exact same system using an USB ex28xx based grabber instead of the > > bttv does not crash. > > > > 1.) Is there a way to diagnose memory corruption in order to ensure that > > it is really a corruption problem and to locate the possible bug? > > > > 2.) Do newer kernel versions have improved bttv drivers (maybe even with > > patched memory corruption issues)? > > > > 3.) As a last resort: Do you know of other Mini-PCI video grabber cards > > that > > are based on other chipsets that are supported by the kernel? > > > > Thanks a lot for any help > > > > Michael > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
