[linux-dvb] cx18: Extensive interrupt and buffer handling changes need test

Andy Walls awalls at radix.net
Wed Nov 19 06:10:37 CET 2008


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.





More information about the linux-dvb mailing list