Overview: Using a firewire camera (Imagingsource DFK 41BF02.h) and Coriander (or other software using the 'libdc1394' library) to get images (video) from the camera. This camera has two pixel modes - MONO8 and YUV422. The issue is that in the YUV422 colour mode the DMA ring buffer seems to get read twice. That is, the video is played twice. The period of repetition depends on the size of the 'DMA ring buffer' which can be set in Coriander. The problem does not occur in the MONO8 colour mode. I am using Arch Linux and encountered the issue under kernel 3.9.7 and 3.9.6. Arch Linux also has a 'linux-lts' package with kernel 3.0.83. The issue goes away if I use kernel 3.0.83. Hardware: F/W: VIA FireWire (IEEE 1394) driven by firewire_ohci CPU: Intel Core i3-2105 M/B: Intel DH77DF Camera: Imagingsource DFK 41BF02.h Steps to Reproduce: 0) Install libraw1394 and Coriander and make sure you have 'video' group permissions. 1) Plug in firewire (non DV) camera. 2) Launch Coriander and go to 'Services' tab 3) Set the format to YUV422 4) Click the 'Display' button so that the camera view window appears. Actual Result: Delayed video from camera with playback at a faster speed and the video repeating once every X number of frames, where X seems to be the DMA ring buffer size which can be set in Coriander Expected Result: Near real time video display from the camera, same as in the Mono 8bpp mode, but in colour. Additional notes: Before trying an older kernel, I also tried downgrading the various libraries and packages involved (libdc1394, libraw1394, Coriander, camwire) and that did not solve the issue under kernel 3.9.7/6.
On Jun 26 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=60171 I can't reproduce this here with Unibrain Fire-i or Apple iSight on VIA VT6306 or TI TSB43AB22A, kernel 3.9 with firewire drivers patched to what is released in kernel 3.10. Using Coriander from an older CVS checkout (shows itself as version 2.0.0-rc5) and libdc1394 from a git checkout from February. Furthermore, I don't remember a similar report from libdc1394-devel which is where many IIDC-on-Linux developers and users are subscribed. Would you be able to invest the necessary time to find the exact pair of 3.n and 3.n+1 kernel versions (alias 3.n.0 and 3.n+1.0) between which the regression was introduced? Compiling the intermediate kernel versions may take some time, but if you do this as a bisection search you will need to test only a few kernels. (No need to test 3.n.m kernels with m > 0, nor 3.n-rc kernels.)
Sure, I think I can do that. I can skip the compile time by installing older packages of the kernel from the Arch Rollback Machine.
Ok, so the regression seems to happen going from 3.3.8 to 3.4.1
On Jun 27 bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=60171 > > --- Comment #3 from Stepan Salenikovich <stepan.salenikovich@gmail.com> > 2013-06-27 00:26:14 --- > Ok, so the regression seems to happen going from 3.3.8 to 3.4.1 Here is the shortlog of the OHCI driver changes from 3.3 to 3.4. (There was no firewire change from 3.4 to 3.4.1.) Clemens Ladisch (8): firewire: ohci: fix too-early completion of IR multichannel buffers firewire: ohci: copy_iso_headers(): make comment match the code firewire: ohci: remove unused excess_bytes field firewire: ohci: optimize control bit checks firewire: ohci: simplify iso header pointer arithmetic firewire: ohci: factor out iso completion flushing code firewire: prevent dropping of completed iso packet header data firewire: allow explicit flushing of iso packet completions David Howells (1): Remove all #inclusions of asm/system.h Stefan Richter (3): firewire: ohci: use dev_printk API firewire: tone down some diagnostic log messages firewire: ohci: move runtime debug facility out of #ifdef Similar to a currently discussed issue with very large video packets (thread "libdc1394 and ladybug3" on libdc1394-devel and linux1394-devel, http://marc.info/?t=137179575200003), it seems to me that "firewire: prevent dropping of completed iso packet header data" is the most likely commit that could be involved in this regression. But I could be wrong; at least I don't quite see the precise trouble spot. Not sure what to do next. (Stepan, I think it works better if you reply by mail with reply-to-all rather than via the bugzilla webform. That way it is easier to Cc more people.)
Fix from Clemens: http://marc.info/?l=linux1394-devel&m=137400617209428
fixed in mainline for v3.11(-rc4...) by https://git.kernel.org/linus/0699a73af381