Richard, (Cc'ing the list)
On Wed, 2008-11-19 at 20:19 -0500, Richard Ayotte wrote: > Hi Andy, > > I just installed the cx18-bugfix driver and everything seems to work > fine. Cool. :) > I did see a: > > [598547.244112] cx18-0 warning: Possibly falling behind: CPU > self-ack'ed our incoming CPU to EPU mailbox (sequence no. 129900) > while processing If you only got 1 of these warnings out of 129,900 buffer transfers, you're in good shape. You've got a pretty responsive system. > while watching live TV on MythTV but it didn't seem to affect it > playback. That's why the messages says "possibly". Most of the time, the driver can still pick up the buffer without problem even though the firmware has given up waiting for the driver to collect the "mail". Occasionally though it is too late, as the firmware has started to send a new piece of "mail". Had you actually lost a buffer, you would have seen a message about "couldn't find buffer" and then some recovery messages afterward: [ 7641.805511] cx18-0: Skipped encoder MPEG, buffer 14, 62 times - it must have dropped out of rotation [ 7641.807258] cx18-0: Returning encoder MPEG, buffer 14 back to transfer rotation You may wish to try dual analog and digital capture in MythTV to stress it. I usually start up the frontend, press "Y" to switch to the analog capture, then use the on screen menu to turn on "picture in picture" to get a digital capture in the small frame. > Thank you for all you work. You're welcome. Thanks for the feedback. Regards, Andy > -- > Richard > > > On Wed, Nov 19, 2008 at 12:10 AM, Andy Walls <[EMAIL PROTECTED]> wrote: > cx18 driver users: > > I have implemented quite a few cx18 driver changes in my > current > experimental repo at > > http://linuxtv.org/hg/~awalls/cx18-bugfix > > The goal behind these changes is to fix problems with > simultaneous > analog and digital capture causing the driver to quit after a > while. > And to fix related problems with buffers getting lost and > falling out of > the driver<->firmware transfer rotation. > > To achieve that result, I had to do extensive rework of how > interrupts > were handled and some buffer handling tweaks. I'm looking for > (brave) > testers to give this stuff a try, or an inspection, before I > ask Mauro > to pull it. I also plan to do testing on my other two > machines in a day > or two. > > Please test the debug parameter with at least info and warn > set: > > # modprobe cx18 debug=3 > > > I am especially interested in > > > 1. How often you get messages like the following on your > system? > > cx18-0 warning: Possibly falling behind: CPU self-ack'ed our > incoming CPU to EPU mailbox (sequence no. nnnn) > > I need to get a feel for if I need to have the cx18 driver not > request a > shared IRQ line for most user applications. > > On my system where irq balance/migration is turned off, and > the HVR-1600 > shares an interrupt with the SATA controller, I get them quite > a bit > doing simultaneous analog and digital capture with MythTV > (I've > approximated a busy, single CPU machine with that setup). > > BTW, the current cx18 driver software processes these > self-ack'ed and > potentially incoherent mailboxes which the firmware has timed > out and > potentially started to overwrite. This change is just nice > enough to > tell you about them, and it also does something more robust > than just > blindly process them. :) > > > 2. If the cx18 driver still works on older machines? > > I got rid of PCI MMIO read retries, as they never seemed to do > anything > useful and wasted time. I needed to get the irq top half > handler > timeline down to as little time as possible. PCI MMIO write > retries > still occur, because those actually get things to work in > older > machines, AFAICT. > > I will also be testing in my one older machine later this > week. > > > Thanks. > > Regards, > Andy > > N.B. If replying to this message, you may wish to prune list > email > addresses for lists for which you are not subscribed. > > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
