So, I finally figured this out, and for the benefit of web posterity and the search engines, I'm gonna lay it out: I was using *both* the register_chrdev() and the cdev_*() functions on the same device.
I guess you can't do that. I can't, anyway. Rubini's scull code uses both, and it looks like he uses both on the same device, although I bet he doesn't (haven't looked closely at the code). I switched to using register_chrdev()/unregister_chrdev() and all is happy now. Thanks to all who helped. On Mon, Dec 30, 2013 at 10:57 AM, Eric Fowler <[email protected]> wrote: > Actually, I was working with a homegrown makefile. I made the change you > recommended and am still having the problem. > > I am thinking now about something else as being the problem. > > Is this code legitimate? > > //// file scope > > struct cdev my_cdev; > > ///inside init function > cdev_init(&my_cdev, ....); > cdev_add(&my_cdev, ....); > > > ///exit fxn > cdev_del(&my_cdev); > > In other words, the memory for the cdev struct comes from static memory > for the driver, not a call to cdev_alloc() or kmalloc(). > > > > > > > On Mon, Dec 30, 2013 at 10:18 AM, Rajat Sharma <[email protected]> wrote: > >> Hi Eric, >> >> I have seen some errors with module reference counting with a nicely >> written code, but culprit for my case was a missing compilation flag >> -DMODULE which gives definition of THIS_MODULE, otherwise it is null e.g. >> for modules which are compiled in kernel, so they are never unloaded. >> Unless you have some customization done to Makefiles, this definition >> should be included, but its anyways good to double check and rule out this >> possibility. >> >> -Rajat >> >> >> On Mon, Dec 30, 2013 at 9:48 AM, Eric Fowler <[email protected]>wrote: >> >>> 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 >>> >>> >> > > > -- > cc:NSA > -- cc:NSA
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
