On Fri, 2009-03-13 at 21:37 -0400, Jeff Campbell wrote: > Hi Andy, > > My apologies for being quiet, I have been tied up on other projects. > I'm back with some fresh feedback and will be more active again now. > > Last night I updated my driver to the latest mainline from the v4l-dvb > repo. > > We have been seeing some consistent problems with the driver being > inoperable after various reboot conditions. > > As a reminder I am running two cx18's on a PCI riser card.
Right I remember. > I did some repeated testing last night and found some interesting > results. > > I did identical tests - booting the system, letting it come on line > and stream from both encoders and then shutting down with the reboot > command. In 3/10 of those cases, I had issues with one or both video > streams on reboot. The other 7/10 times both streams came back fine. > I adjusted no other settings. When I had issues, on one card I had > video and no audio, sometimes I had nothing but a black, grey or red > screen. Once I also had video only on the second card. > > I then did some experimenting and discovered that if I stopped > accessing the device and did an rmmod and then a new modprobe, I would > restore full video and audio on both devices. > > I then did 10 more identical tests. This time I powered on the box, > let it boot to operational and then powered it off (hard power off, no > shut down is done on the OS side - don't worry I'm running from ram, > no disk sync issues). This time 8/10 of the boots failed and only > 2/10 worked properly. Again, if I log in, stop accessing the device, > unload the cx18 module and reload it, everything returns to normal. > > After observing these issues, I modified my boot script to do a > modprobe during early init, immediately do an rmmod and then do > another modprobe. After I made that change I repeated my tests doing > both soft reboot and hard power off resets of the device. All 10/10 > of those tests were successful with both video and audio working fine > for both streams. That is very good feedback. The important part is the repeatability of the problem and the repeatability of the resolution. That means with some well placed debug statements, differential analysis can show what is going on. The "well placed" will be the hard part. > I am unable to offer any suggestion as to what exactly is causing it, > but it does appear that there are some issues with the initialization > process that seem to be cured in the process of the removal of the > module such that a subsequent insert works properly. I hope that is > enough testing feedback to help you locate whatever may be causing the > issue. I'll make a repo in the next week with some extra debug and some extra verification of firmware load. My thought is that the routines in cx18-io.[ch] are reaching their retry limit due to the PCI bus being very busy and a register or memory location not getting written properly. Doing it again gets all the registers and memory locations written properly. A quick "fix" would be to increase the retry limit. Also some debug statements about when the retry limit is reached may provide some positive confirmation of my hypothesis. Then if that doesn't work I'll press for information on the CX18_AUDIO_ENABLE register which just plain bothers me in it's behavior. Regards, Andy > If you need me to check something else, please let me know. > > -Jeff > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
