On Tue, 2005-07-12 at 16:08 +0200, Mateusz Berezecki wrote: > Sorry for not being too precise. Yes, your assumptions were correct ;-) > I grab a lock using > > spin_lock(&ieee->lock); > > and release it using > > spin_unlock(&ieee->lock); > > there is quite a lot of debugging printk's inbetween. Can this be a cause ? >
No. You previous showed the following output: scheduling while atomic: insmod/0x00000001/12692 [<c03e7352>] schedule+0x632/0x640 [<c0119bb1>] __wake_up_common+0x41/0x70 [<c03e74df>] wait_for_completion+0x8f/0xf0 [<c0119b50>] default_wake_function+0x0/0x20 [<c0119b50>] default_wake_function+0x0/0x20 [<c012e2dd>] queue_work+0x8d/0xa0 [<c012e070>] __call_usermodehelper+0x0/0x70 [<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0 [<c012e070>] __call_usermodehelper+0x0/0x70 [<c020c028>] sprintf+0x28/0x30 [<c020955d>] kobject_hotplug+0x29d/0x310 [<c019fc6e>] sysfs_create_link+0x3e/0x60 [<c028b601>] class_device_add+0x161/0x1e0 [<c036f38e>] netdev_register_sysfs+0x3e/0x100 [<c03650db>] netdev_run_todo+0x1eb/0x220 [<c0364dce>] register_netdev+0x5e/0x90 I assume that you call register_netdev in your module. Since this was running insmod, this is probably called from the module_init. So what reason do you have a lock from beginning to end? Looking at this, you can't call register_netdev while holding a spin_lock since it looks like it will schedule. So the fix is to release whatever spin lock that you have before calling register_netdev. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
