On Wed, 2009-07-22 at 08:00 +0100, Ian Armstrong wrote:
> On Wednesday 22 July 2009, Andy Walls wrote:

> >
> > This is a fb infrastructure problem in my opinion.  Maybe ivtvfb is
> > doing something wrong which causes unregister_framebuffer() to fail, but
> > unregister_framebuffer() shouldn't be leaving its internal data
> > structures in an inconsistent state upon failure.  Module unloading
> > simply shouldn't fail or cause kernel corruption, IMO.  I assume ivtvfb
> > emitted "Framebuffer 0 is in use, cannot unload" in one of your logs.

> 
> It appeared to be linked to the kernel config. Using my normal config, 
> unloading the ivtvfb module would remove the entry from /proc/fb. With the 
> offending config, although the module would unload, the /proc/fb entry would 
> persist. At the time, I was able to reproduce this using another framebuffer 
> driver, which implied the bug was not in the ivtvfb code itself.
> 
> In the event that an error occurs when trying to unregister the framebuffer, 
> the ivtvfb module should issue a warning, but behaviour beyond this point is 
> undefined. Given that you shouldn't be able to unload the module if the 
> framebuffer is in use, this situation should never arise.

If unregister_framebuffer() fails ivtvfb issues the warning that the
framebuffer was in use (which doesn't strcitly have to be the case I
think, but ivtvfb has no insight into the failure mode).  A failure mode
in unregister_framebuffer() is the FB_EVENT_FB_UNBIND notification
returning failure.  

But in the event of any such failure, ivtvfb_callback_cleanup() and
ivtvfb_cleanup() simply continue on.  There's not too much else ivtvfb
can reasonable do, as the module will be unloaded shortly after
ivtvfb_cleanup() returns.

Maybe ivtvfb needs to implement an ivtvfb_ops.fb_release callback?  I'll
have to look into the possible FB_EVENT_FB_UNBIND failures later this
weekend (Sunday?) when I'm done all my other stuff.  I'll be climbing
the learning curve on getting my loaner PVR-350 card configured though.

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to