Re: [2.6 patch] videobuf-core.c locking fixes
Em Qua, 2007-12-12 às 16:22 -0500, Shane escreveu: > > Yes it does! I was just going to send the same patch myself :) > > But, I am now seeing some errors that weren't there in 2.6.23 > > kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* > last message repeated 15 times > kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, > bits: HSYNC OFLOW > kernel: bttv0: reset, reinitialize > kernel: bttv0: PLL can sleep, using XTAL (28636363). > > kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* > last message repeated 15 times > kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, > bits: HSYNC OFLOW > kernel: bttv0: reset, reinitialize > kernel: bttv0: PLL can sleep, using XTAL (28636363). > > These happen occasionally and it causes an EIO DQBUF > error and the application has to re queue the buffers but it > recovers OK. Not sure if it causes some sort of internal > kernel corruption that will only be noticed later possibly? > > I am using 15 userptr buffers so whatever is happening may > be happening once per buffer sometimes. dunno You may see such troubles with weak signals, where bttv is not capable of getting the proper sync. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
Em Qua, 2007-12-12 às 16:22 -0500, Shane escreveu: Yes it does! I was just going to send the same patch myself :) But, I am now seeing some errors that weren't there in 2.6.23 kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). These happen occasionally and it causes an EIO DQBUF error and the application has to re queue the buffers but it recovers OK. Not sure if it causes some sort of internal kernel corruption that will only be noticed later possibly? I am using 15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno You may see such troubles with weak signals, where bttv is not capable of getting the proper sync. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
> > e1f8b4a49d86746f699919531c17fd154787e308
> > diff --git a/drivers/media/video/videobuf-core.c
> > b/drivers/media/video/videobuf-core.c
> > index 81f77d2..c8a5cb5 100644
> > --- a/drivers/media/video/videobuf-core.c
> > +++ b/drivers/media/video/videobuf-core.c
> > @@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
> > if (q->streaming)
> > goto done;
> > if (!q->reading) {
> > - retval = videobuf_read_start(q);
> > + retval = __videobuf_read_start(q);
> > if (retval < 0)
> > goto done;
> > }
> > @@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
> > struct videobuf_buffer, stream);
> > } else {
> > if (!q->reading)
> > - videobuf_read_start(q);
> > + __videobuf_read_start(q);
> > if (!q->reading) {
> > rc = POLLERR;
> > } else if (NULL == q->read_buf) {
> >
>
> Yes it does! I was just going to send the same patch myself :)
The patch seems ok to my eyes. I dunno why I forgot to replace those two
occurrences on my patch :(
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
e1f8b4a49d86746f699919531c17fd154787e308
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 81f77d2..c8a5cb5 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
if (q-streaming)
goto done;
if (!q-reading) {
- retval = videobuf_read_start(q);
+ retval = __videobuf_read_start(q);
if (retval 0)
goto done;
}
@@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
struct videobuf_buffer, stream);
} else {
if (!q-reading)
- videobuf_read_start(q);
+ __videobuf_read_start(q);
if (!q-reading) {
rc = POLLERR;
} else if (NULL == q-read_buf) {
Yes it does! I was just going to send the same patch myself :)
The patch seems ok to my eyes. I dunno why I forgot to replace those two
occurrences on my patch :(
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
> Yes it does! I was just going to send the same patch myself :) But, I am now seeing some errors that weren't there in 2.6.23 kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). These happen occasionally and it causes an EIO DQBUF error and the application has to re queue the buffers but it recovers OK. Not sure if it causes some sort of internal kernel corruption that will only be noticed later possibly? I am using 15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
On Dec 12, 2007 2:44 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote:
> > 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:
> > > > 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.
> >
> > Ugh, after further testing with a bttv card it seems this is not fine.
> >
> > vbi doesn't work anymore and my application gets stuck in a Zombie,
> > unkillable, have to reboot state :(
> >
> > mythtv3683 1 -3 2.4 0.0 0 0 ?Z > 00:00:06 [mythbackend]
> >
> > Reverting Mauro's patch above does fix the problem.
>
> Thanks for testing, does the patch below fix it?
>
> > Shane
>
> cu
> Adrian
>
>
> <-- snip -->
>
>
> After commit 19fb1457990b6b7e15586ec7331541a184233acc the callers in
> videobuf-core.c that already hold the lock must call
> __videobuf_read_start() instead of videobuf_read_start().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/media/video/videobuf-core.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> e1f8b4a49d86746f699919531c17fd154787e308
> diff --git a/drivers/media/video/videobuf-core.c
> b/drivers/media/video/videobuf-core.c
> index 81f77d2..c8a5cb5 100644
> --- a/drivers/media/video/videobuf-core.c
> +++ b/drivers/media/video/videobuf-core.c
> @@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
> if (q->streaming)
> goto done;
> if (!q->reading) {
> - retval = videobuf_read_start(q);
> + retval = __videobuf_read_start(q);
> if (retval < 0)
> goto done;
> }
> @@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
> struct videobuf_buffer, stream);
> } else {
> if (!q->reading)
> - videobuf_read_start(q);
> + __videobuf_read_start(q);
> if (!q->reading) {
> rc = POLLERR;
> } else if (NULL == q->read_buf) {
>
Yes it does! I was just going to send the same patch myself :)
Shane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
On Dec 12, 2007 2:44 PM, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote:
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:
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.
Ugh, after further testing with a bttv card it seems this is not fine.
vbi doesn't work anymore and my application gets stuck in a Zombie,
unkillable, have to reboot state :(
mythtv3683 1 -3 2.4 0.0 0 0 ?Zl 13:40:35
00:00:06 [mythbackend] defunct
Reverting Mauro's patch above does fix the problem.
Thanks for testing, does the patch below fix it?
Shane
cu
Adrian
-- snip --
After commit 19fb1457990b6b7e15586ec7331541a184233acc the callers in
videobuf-core.c that already hold the lock must call
__videobuf_read_start() instead of videobuf_read_start().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/media/video/videobuf-core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
e1f8b4a49d86746f699919531c17fd154787e308
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 81f77d2..c8a5cb5 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -909,7 +909,7 @@ ssize_t videobuf_read_stream(struct videobuf_queue *q,
if (q-streaming)
goto done;
if (!q-reading) {
- retval = videobuf_read_start(q);
+ retval = __videobuf_read_start(q);
if (retval 0)
goto done;
}
@@ -982,7 +982,7 @@ unsigned int videobuf_poll_stream(struct file *file,
struct videobuf_buffer, stream);
} else {
if (!q-reading)
- videobuf_read_start(q);
+ __videobuf_read_start(q);
if (!q-reading) {
rc = POLLERR;
} else if (NULL == q-read_buf) {
Yes it does! I was just going to send the same patch myself :)
Shane
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] videobuf-core.c locking fixes
Yes it does! I was just going to send the same patch myself :) But, I am now seeing some errors that weren't there in 2.6.23 kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=105615/105615, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1fa0401c,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=16 irq=106741/106741, risc=1fa0401c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). These happen occasionally and it causes an EIO DQBUF error and the application has to re queue the buffers but it recovers OK. Not sure if it causes some sort of internal kernel corruption that will only be noticed later possibly? I am using 15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
