On Wednesday 22 July 2009, Andy Walls wrote: > The oops happens because fbops->owner points to a module that obviously > has been unloaded and it's vmalloc() allocation destroyed. > > The registered_fb[] array must have stale data in it. > > I don't have 2.6.29 kernel source in front of me (the snippet above I > pulled from an LXR website) and the fb kernel code has obviously changed > since my 2.6.27 kernel source I have on hand. > > What i do find surprising in my 2.6.27 source code is that > linux/drivers/video/fbmem.c:unregister_framebuffer() can actually > *fail*, leaving the stale information in the registered_fb[] array when > a module like ivtvfb unloads. > > 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.
If this is the problem I'm thinking of, it's a long standing bug that was reported once before, though not to this list. I'll admit that I'd forgotten about it until it was mentioned here. 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. -- Ian _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
