On Wednesday 17 January 2007 00:53, David Engel wrote:
> I've been tracking down a nasty problem with my MythTV backend for a
> couple of weeks. Long story short, I tracked it down to Myth's use
> of the archaic 0xffee7703/IVTV_IOC_G_CODEC ioctl and the ivtv
> 0.[89].x driver's handling of it. Whether or not Myth should be
> using such an old, obsoleted ioctl is another matter. I'm dealing
> with that elsewhere.
>
> What I'm bringing up here is why Myth's use of 0xffee7703 causes a
> problem. The first time I start mythbackend after a reboot,
> everything is fine. However, if I ever restart mythbackend without
> rebooting, it's virtual size shoots up to 2 GB after the 0xffee7703
> ioctl is issued. This causes various other things to start failing
> with ENOMEM errors. If I cnange Myth to not issue 0xffee7703 and
> instead "fallback" to the newer v4l2 ioctls, it all works just fine.
>
> So what's going wrong? The driver properly returns EINVAL when given
> the obsolete ioctl, but it sure looks like the driver is doing
> something bad to the mythbackend process. At first I thought
> video_usercopy() might be scribbling over user memory because it
> mis-interpreted the read-write action and argument size [not] encoded
> in the ioctl number. I'm not so sure after looking at it closer.
Should be fixed in the ivtv-0.8/-0.9/trunk. video_usercopy is indeed
responsible. Thanks for reporting this.
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
