(please CC on replies, I'm not on the list)
Hi,
When there is a background thread doing VIDIOCSYNC in a loop, issuing
VIDIOCSPICT in the current thread on the same file descriptor causes
it to go into uninterruptable sleep and hang. This is on kernel 2.6.8
using the bttv driver, and appears easily reproducible.
Anyone any ideas?
thanks,
Lennert
On Mon, Oct 25, 2004 at 05:18:41PM +0200, Gerd Knorr wrote:
> > When there is a background thread doing VIDIOCSYNC in a loop, issuing
> > VIDIOCSPICT in the current thread on the same file descriptor causes
> > it to go into uninterruptable sleep and hang. This is on kernel 2.6.8
> > using the bttv driver, and appears easily reproducible.
>
> Don't do that. bttv serializes ioctls with a lock. Well, not all of
> them, but the ones which change the state of the filehandle, and both
> VIDIOCSYNC + VIDIOCSPICT fall into that group. You simply can't run
> them in parallel on the same filehandle.
OK, even though it worked fine on 2.4 I'll buy that, but it still
shouldn't result in an unkillable process, should it?
cheers,
Lennert
On Mon, Oct 25, 2004 at 05:03:49PM +0200, Lennert Buytenhek wrote:
> (please CC on replies, I'm not on the list)
>
> Hi,
>
> When there is a background thread doing VIDIOCSYNC in a loop, issuing
> VIDIOCSPICT in the current thread on the same file descriptor causes
> it to go into uninterruptable sleep and hang. This is on kernel 2.6.8
> using the bttv driver, and appears easily reproducible.
Don't do that. bttv serializes ioctls with a lock. Well, not all of
them, but the ones which change the state of the filehandle, and both
VIDIOCSYNC + VIDIOCSPICT fall into that group. You simply can't run
them in parallel on the same filehandle.
Gerd
--
#define printk(args...) fprintf(stderr, ## args)
On Mon, Oct 25, 2004 at 06:01:45PM +0200, Lennert Buytenhek wrote:
> On Mon, Oct 25, 2004 at 05:18:41PM +0200, Gerd Knorr wrote:
>
> > > When there is a background thread doing VIDIOCSYNC in a loop, issuing
> > > VIDIOCSPICT in the current thread on the same file descriptor causes
> > > it to go into uninterruptable sleep and hang. This is on kernel 2.6.8
> > > using the bttv driver, and appears easily reproducible.
> >
> > Don't do that. bttv serializes ioctls with a lock. Well, not all of
> > them, but the ones which change the state of the filehandle, and both
> > VIDIOCSYNC + VIDIOCSPICT fall into that group. You simply can't run
> > them in parallel on the same filehandle.
>
> OK, even though it worked fine on 2.4 I'll buy that, but it still
> shouldn't result in an unkillable process, should it?
Does it? That wasn't clear. One of the two threads (the one waiting
for the lock, probably the one doing VIDIOCSPICT) might be unkillable.
Try killing the other thread as well, that should work. If it doesn't
I'd like to get stack traces for the deadlock case (sysrq-t).
Gerd
--
#define printk(args...) fprintf(stderr, ## args)