Em Qua, 2007-12-12 às 23:19 +0100, Jean Delvare escreveu:
> Hi Mauro,
>
> On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
> > What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
> > fixed some bad locks.
> >
> > After this changeset, videobuf_read_stream()
Em Qua, 2007-12-12 às 23:19 +0100, Jean Delvare escreveu:
Hi Mauro,
On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
fixed some bad locks.
After this changeset, videobuf_read_stream() holds
Hi Mauro,
On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
> What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
> fixed some bad locks.
>
> After this changeset, videobuf_read_stream() holds q->lock and calls
> videobuf_read_start(). To avoid waiting
On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> ...
> > The proper solution is provided by this changeset:
> >
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
...
> The proper solution is provided by this changeset:
> http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc
I applied this and it seems fine with a bttv
Em Qua, 2007-12-12 às 13:03 +0100, Adrian Bunk escreveu:
> On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
> >...
> > I'm afraid that this wouldn't avoid this bug, however.
> >
> > The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
> > Brandon, since he
On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
>...
> I'm afraid that this wouldn't avoid this bug, however.
>
> The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
> Brandon, since he renamed the function, removing the locks. I think he
> didn't noticed
> Any objections against a later path that changes the exports to the
> general "immediately after the function" convention?
No objections. Please generate against "devel" branch on my -git, since
I did a patch fixing most CodingStyle issues reported by checkpatch.pl.
Several files under /media
Em Qua, 2007-12-12 às 00:20 -0500, Shane escreveu:
> In 2.6.24-rc5+, I hit this problem with videobuf_read_start
> not being exported. Patch attached, only compile tested.
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK
On Wed, 2007-12-12 at 00:20 -0500, Shane wrote:
> In 2.6.24-rc5+, I hit this problem with videobuf_read_start
> not being exported. Patch attached, only compile tested.
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK
Patch looks good, it seems a merge conflict of
commit 19bc5133dae9562e8824ef101464061f9854c1d8
was resolved the wrong way.
@Mauro:
Any objections against a later path that changes the exports to the
general "immediately after the function" convention?
It would have avoided at least two such bugs
Patch looks good, it seems a merge conflict of
commit 19bc5133dae9562e8824ef101464061f9854c1d8
was resolved the wrong way.
@Mauro:
Any objections against a later path that changes the exports to the
general immediately after the function convention?
It would have avoided at least two such bugs
On Wed, 2007-12-12 at 00:20 -0500, Shane wrote:
In 2.6.24-rc5+, I hit this problem with videobuf_read_start
not being exported. Patch attached, only compile tested.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK
Em Qua, 2007-12-12 às 00:20 -0500, Shane escreveu:
In 2.6.24-rc5+, I hit this problem with videobuf_read_start
not being exported. Patch attached, only compile tested.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK
Any objections against a later path that changes the exports to the
general immediately after the function convention?
No objections. Please generate against devel branch on my -git, since
I did a patch fixing most CodingStyle issues reported by checkpatch.pl.
Several files under /media still
On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
...
I'm afraid that this wouldn't avoid this bug, however.
The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
Brandon, since he renamed the function, removing the locks. I think he
didn't noticed that
Em Qua, 2007-12-12 às 13:03 +0100, Adrian Bunk escreveu:
On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
...
I'm afraid that this wouldn't avoid this bug, however.
The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
Brandon, since he renamed the
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
...
The proper solution is provided by this changeset:
http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h=19fb1457990b6b7e15586ec7331541a184233acc
I applied this and it seems fine with a bttv card.
On Dec 12, 2007 11:37 AM, Shane [EMAIL PROTECTED] wrote:
On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote:
...
The proper solution is provided by this changeset:
Hi Mauro,
On Wed, 12 Dec 2007 12:21:56 -0200, Mauro Carvalho Chehab wrote:
What happened is that changeset 19bc5133dae9562e8824ef101464061f9854c1d8
fixed some bad locks.
After this changeset, videobuf_read_stream() holds q-lock and calls
videobuf_read_start(). To avoid waiting forever for
In 2.6.24-rc5+, I hit this problem with videobuf_read_start
not being exported. Patch attached, only compile tested.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
CC [M]
In 2.6.24-rc5+, I hit this problem with videobuf_read_start
not being exported. Patch attached, only compile tested.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
CC [M]
22 matches
Mail list logo
