On Fri, 2008-11-28 at 16:23 -0500, Jeff Campbell wrote: > My apologies, my paste was truncated. Here is the full paste for ~20 > minutes of tuner capture: >
> Nov 28 21:09:51 enc239-009-060 kernel: cx18-0 info: Start encoder stream > encoder MPEG > Nov 28 21:09:53 enc239-009-060 kernel: cx18-0 warning: sending > CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement There's not much we can do about the firmware ignoring us for a long time. This warning just lets you know it happened. It usually means the firmware is very busy. The first one happened within the first few seconds of capture which would make sense as to why the firmware might be very busy. > Nov 28 21:11:16 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 3559) > while processing > Nov 28 21:11:39 enc239-009-060 kernel: cx18-0 warning: sending > CX18_CPU_DE_SET_MDL timed out waiting 12 msecs for RPU acknowledgement > Nov 28 21:12:31 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 6759) > while processing > Nov 28 21:12:55 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 7734) > while processing > Nov 28 21:15:20 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 13450) > while processing > Nov 28 21:16:15 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 15727) > Nov 28 21:18:55 enc239-009-060 kernel: cx18-0 warning: Possibly falling > behind: CPU self-ack'ed our incoming CPU to EPU mailbox (sequence no. 22625) > enc239-009-060:~# > > Well, the firmware holds us to a very tight timeline for picking up a message and acknowledging it. Once we ack the mailbox we got, or the firmware moves on (self-ack's the mailbox message), the firmware is free to change the contents of the mailbox. This doesn't mean the firmware has actually changed the mailbox yet, only that it may. It means we missed the firmware's imposed interrupt processing latency timeline for that one buffer transfer. But note: the first four are suffixed with "while processing", which means we got a known good copy of the mailbox and buffer pointer data, but by the time we went to ack the mailbox, the firmware had moved on. For the last two, we actually were late picking up the mailbox and could have been working with incoherent data. The reality is that often the data is still good and we process it anyway with some additional sanity checks. Had you actually lost a buffer, there would have been follow on messages about finding a lost buffer and putting it back into rotation. In short nothing "bad" actually happened. The possibility of the host falling behind wasn't realized and you never lost a buffer. Plus, they're really far apart, if you look at the sequence numbers: 3559, 6759, 7734, 13450 & 15727, 22625. In most cases, they were thousands of transfers apart. How often you get this messages will really be dependent on the interrupt processing latency of your *system* and the latency of your PCI bus, a shared *system* resource. I've done about as much as I can in the cx18 driver to shorten up the interrupt processing timeline. The rest is up to the kernel and other drivers not hogging the CPU's with spinlocks and devices and the kernel and drivers not hogging the PCI bus. If you really *want to generate* a lot of these messages from the cx18 driver you can: a) Do a simultaneous analog and digital capture from the same CX23418. The firmware gets impatient quite often in this case. or b) have the CX23418 share an interrupt with a busy device (e.g. disk or graphics or network controller) that has a device driver whose interrupt handler is poorly written (i.e. slow). Case b is usually avoidable with system reconfiguration. Case a is just the nature of the beast. Anyway, this sort of thing has always been going on. It's just now the cx18 driver is optimized to really try avoid it, checks for it and can warn you when it happens, and actively cleans up the buffer handling problems that used to occur because of it. BTW this is in now way intended to knock Hans' excellent work in getting a working driver fielded by last Christmas. Had Hans not done that, I wouldn't have bought an HVR-1600 or even cared about a driver. I am a firm believer in the "it is only because I stand on the shoulders of giants" explanation of how technology, science, and software progress. :) Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
