Bug 60171

Summary:	firewire camera - DMA ring buffer being read/played twice in YUV422 mode
Product:	Drivers	Reporter:	Stepan Salenikovich (stepan.salenikovich)
Component:	IEEE1394	Assignee:	drivers_ieee1394
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	stefanr
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.9.7, 3.9.6	Subsystem:
Regression:	Yes	Bisected commit-id:

Description Stepan Salenikovich 2013-06-26 19:01:36 UTC

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.

Comment 1 Stefan Richter 2013-06-26 21:59:48 UTC

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.)

Comment 2 Stepan Salenikovich 2013-06-26 22:10:40 UTC

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.

Comment 3 Stepan Salenikovich 2013-06-27 00:26:14 UTC

Ok, so the regression seems to happen going from 3.3.8 to 3.4.1

Comment 4 Stefan Richter 2013-07-16 13:47:33 UTC

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.)

Comment 5 Stefan Richter 2013-07-18 20:53:18 UTC

Fix from Clemens:
http://marc.info/?l=linux1394-devel&m=137400617209428

Comment 6 Stefan Richter 2013-07-30 14:07:58 UTC

fixed in mainline for v3.11(-rc4...) by https://git.kernel.org/linus/0699a73af381