On Fri, 2009-03-13 at 22:58 -0400, Andy Walls wrote: > 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, Please test the changes at http://linuxtv.org/hg/~awalls/cx18-init-debug The changes do a few things: 1. Verify the A/V digitizer core audio standard autodetection firmware image was loaded properly, and logs a message. 2. Log a message when we write to a register and fail to read back what we wrote, or fail to read back what we expected to read back, after several retries. 3. Whenever we write to the CX18_AUDIO_ENABLE register, force bits that we can read back to toggle, so we know we have actually written to the register. I got this right on input change: Tuner, SVideo 1, CVBS 1, Svideo 2, CVBS2. I may have goofed this slightly in the initialization, function though. (I'm too tired right now.) If you could repeat a few experiments and let me know if you see any messages regarding failure in the log. I don't think you need to set any debug switches. Regards, Andy > > -Jeff _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
