Still working on this. Here is some dmesg spew: [ 514.245846] foobar: module verification failed: signature and/or required key missing - tainting kernel [ 514.245937] kobject: 'foobar' (f7f060c8): kobject_add_internal: parent: 'module', set: 'module' [ 514.245951] kobject: 'holders' (f5ff3d40): kobject_add_internal: parent: 'foobar', set: '<NULL>' [ 514.245981] kobject: 'notes' (f2d25f80): kobject_add_internal: parent: 'foobar', set: '<NULL>' [ 514.245987] kobject: 'foobar' (f7f060c8): kobject_uevent_env [ 514.245998] kobject: 'foobar' (f7f060c8): fill_kobj_path: path = '/module/foobar'
So it looks like kernel validation is failing. I have printk's in my init fxn that are never turning up in /var/log/messages, until, weirdly, AFTER I remove the device: <insmod device> Dec 30 09:43:03 localhost kernel: [ 514.245846] foobar: module verification failed: signature and/or required key missing - tainting kernel Dec 30 09:43:16 localhost fprintd[1085]: ** Message: No devices in use, exit <rmmod device> Dec 30 09:45:53 localhost kernel: [ 514.249323] foobar: got device number 248, minor is 0 <<<<----THIS IS IN init() fxn Dec 30 09:45:53 localhost kernel: [ 684.102912] unregister_chrdev(248) called for foobar<7>[ 684.102927] kobject: '(null)' (f7f06220): kobject_cleanup, parent (null) <insmod> insmod: ERROR: could not insert module ./foobar.ko: Device or resource busy On Fri, Dec 27, 2013 at 9:13 PM, <[email protected]> wrote: > On Fri, 27 Dec 2013 19:33:50 -0800, Eric Fowler said: > > > I suspect I am doing something wrong in the code with > > register/unregister_chrdev(), but I have been over that code a million > > times. It looks fine. > > > > Now: > > insmod the device, OK > > rmmod the device, OK > > Check /proc/devices , device # is present > > insmod the device again, fails with ERROR: could not insert module > > ./foobar.ko: Device or resource busy > > It does smell like an unregister issue. You may want to try adding > printk() calls to print out the return code from register and unregister. > I'm willing to bet that (a) the unegister is failing because somebody > still has a reference on the device, and (b) the second register call fails > because the device already exists, causing your module_init() to bail out. > > The fun is that you may not have taken a reference on the device directly > yourself - you may have called some other get_foo() that ends up taking an > implicit reference under the covers, causing issues when you fail to call > put_foo() at the right place... > -- cc:NSA
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
