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. David -- David Engel [EMAIL PROTECTED] _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
