It turns out that the patch below causes a build failure on the
2.6.27.40 kernel.
Michael, should I just drop it, or should I take out the line with the
"capture_transfer_done" in it, as that member is not in the structure in
this kernel version.
thanks,
greg k-h
On Thu, Oct 15, 2009 at 01:14:34AM -0300, Devin Heitmueller wrote:
> From: Devin Heitmueller <[email protected]>
>
> commit 96fbf771d86a90ff006bc62ca4d4de6474b3de31 upstream.
>
> Because the counters were not reset when starting up streaming, they would
> be reused from the previous run. This can result in cases such that when the
> second instance of streaming starts up, the "cnt" variable in
> em28xx_audio_isocirq() can end up being negative, resulting in attempting to
> write to memory before the start of runtime->dma_area (as well as having a
> negative number of bytes to copy).
>
> Signed-off-by: Devin Heitmueller <[email protected]>
> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Michael Krufky <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/media/video/em28xx/em28xx-audio.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> --- a/drivers/media/video/em28xx/em28xx-audio.c
> +++ b/drivers/media/video/em28xx/em28xx-audio.c
> @@ -365,6 +365,11 @@ static int snd_em28xx_hw_capture_free(st
>
> static int snd_em28xx_prepare(struct snd_pcm_substream *substream)
> {
> + struct em28xx *dev = snd_pcm_substream_chip(substream);
> +
> + dev->adev.hwptr_done_capture = 0;
> + dev->adev.capture_transfer_done = 0;
> +
> return 0;
> }
>
On Tue, Dec 8, 2009 at 4:42 PM, Greg KH <[email protected]> wrote:
> It turns out that the patch below causes a build failure on the
> 2.6.27.40 kernel.
>
> Michael, should I just drop it, or should I take out the line with the
> "capture_transfer_done" in it, as that member is not in the structure in
> this kernel version.
>
> thanks,
>
> greg k-h
There were several different leaks and crash conditions addressed
since 2.6.27, and it is entirely possible that just removing the line
is not the correct course of action.
I would propose just dropping the patch for 2.6.27, as we would have
to rework it taking into consideration the other fixes which were done
since then.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
On Tue, Dec 08, 2009 at 04:49:14PM -0500, Devin Heitmueller wrote:
> On Tue, Dec 8, 2009 at 4:42 PM, Greg KH <[email protected]> wrote:
> > It turns out that the patch below causes a build failure on the
> > 2.6.27.40 kernel.
> >
> > Michael, should I just drop it, or should I take out the line with the
> > "capture_transfer_done" in it, as that member is not in the structure in
> > this kernel version.
> >
> > thanks,
> >
> > greg k-h
>
> There were several different leaks and crash conditions addressed
> since 2.6.27, and it is entirely possible that just removing the line
> is not the correct course of action.
>
> I would propose just dropping the patch for 2.6.27, as we would have
> to rework it taking into consideration the other fixes which were done
> since then.
Ok, I'll go do that.
thanks,
greg k-h
On Tue, Dec 8, 2009 at 4:49 PM, Devin Heitmueller
<[email protected]> wrote:
> On Tue, Dec 8, 2009 at 4:42 PM, Greg KH <[email protected]> wrote:
>> It turns out that the patch below causes a build failure on the
>> 2.6.27.40 kernel.
>>
>> Michael, should I just drop it, or should I take out the line with the
>> "capture_transfer_done" in it, as that member is not in the structure in
>> this kernel version.
>>
>> thanks,
>>
>> greg k-h
>
> There were several different leaks and crash conditions addressed
> since 2.6.27, and it is entirely possible that just removing the line
> is not the correct course of action.
>
> I would propose just dropping the patch for 2.6.27, as we would have
> to rework it taking into consideration the other fixes which were done
> since then.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
Greg,
Yes -- please drop it for now. I didn't actually send this for
2.6.27.y anyway -- it must have gotten to you some other way.
Devin, if 2.6.27.y needs this fix, can you please generate the
appropriate backport and test it before we resubmit?
Cheers,
Mike Krufky
On Tue, Dec 8, 2009 at 6:02 PM, Michael Krufky <[email protected]> wrote:
> Yes -- please drop it for now. ?I didn't actually send this for
> 2.6.27.y anyway -- it must have gotten to you some other way.
>
> Devin, if 2.6.27.y needs this fix, can you please generate the
> appropriate backport and test it before we resubmit?
We would have to decide whether it's worth the effort to get a 2.6.27
environment setup to do the necessary regression testing. At this
point, I would argue that driver was screwed up enough in 2.6.27 that
I wouldn't be inclined to tell users it worked even with this one fix.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
On Tue, Dec 8, 2009 at 6:11 PM, Devin Heitmueller
<[email protected]> wrote:
> On Tue, Dec 8, 2009 at 6:02 PM, Michael Krufky <[email protected]> wrote:
>> Yes -- please drop it for now. ?I didn't actually send this for
>> 2.6.27.y anyway -- it must have gotten to you some other way.
>>
>> Devin, if 2.6.27.y needs this fix, can you please generate the
>> appropriate backport and test it before we resubmit?
>
> We would have to decide whether it's worth the effort to get a 2.6.27
> environment setup to do the necessary regression testing. ?At this
> point, I would argue that driver was screwed up enough in 2.6.27 that
> I wouldn't be inclined to tell users it worked even with this one fix.
>
> Devin
Fine with me -- I'm glad the v4l-dvb development repositories hosted
on both linuxtv.org and kernellabs.com are backwards compatible with
recent kernels... :-)
I think all the crucial fixes (except for the pvrusb2 16k firmware
patch) are all merged into 2.6.31.y as of now... So, now we can focus
on new driver support for 2.6.32 :-)
Cheers,
Mike