> > 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 0.8.34 is known buggy. 0.8.44 should do well. 0.8.45 too in theory, but there are a number of mm changes which didn't got that much testing so far ... > Ive also run 0.8.33 on newer kernels with no problem. Hmm, ok. > > 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. Hmm, maybe the error path in btaudio is buggy, althrougth I can't see any obvious on a first quick check of the code ... > here is a little more logging of what it > looks like right before a crash: > [ snip ] looks like normal operation. > > > 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. Can you try that with rmmoding bttv+video-buf and btaudio separately? I'd like to know which of the two causes the oops. Gerd -- You can't please everybody. And usually if you _try_ to please everybody, the end result is one big mess. -- Linus Torvalds, 2002-04-20
