Re: Race in gspca main or missing lock in stv06xx subdriver?

[Jean-Francois Moine <moinejf@free.fr>]

On Sun, 04 Oct 2009 17:36:55 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> As Jean-Francois very correctly pointed out, but no worries. The
> handling of isoc irq's is serialised elsewhere in the kernel, the
> issue of what James is seeing is much simpler.
> 
> When we call gspca_frame_add, it returns a pointer to the frame
> passed in, unless we call it with LAST_PACKET, when it will return a
> pointer to a new frame in to whoch store the frame data for the next
> frame. So whenever calling:
> gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, len);
> we should do this as:
> frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame, data, len);
> 
> So that any further data got from of the pkt we are handling in
> pkt_scan, goes to the next frame.
> 
> We are not doing this in stv06xx.c pkt_scan method, which the cause
> of what James is seeing. So I started checking all drivers, and we
> are not doing this either in ov519.c when handling an ov518 bridge.
> So now the framerate of my 3 ov518 test cams has just doubled. Thanks
> James!
> 
> I'll send a patch with the fix in a separate mail.

Hello Hans,

Thank you for the patch. Yes, it was simple and I should have seen it
before! I think this problem could be avoided if the frame pointer is
not given to the pkt_scan function (if the subdriver needs it, it is
returned by gspca_get_i_frame).

Best regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/