modprobe processor.ko && sleep 1 && rmmod processor can cause a panic [which is ignored, see BUG #2349] if CONFIG_PREEMPT is enabled: ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states) Badness in remove_proc_entry at fs/proc/generic.c:660 Call Trace: [<c017d18c>] remove_proc_entry+0x10c/0x140 [<d05c19fe>] acpi_processor_remove_fs+0x46/0x69 [processor] [<d05c1f45>] acpi_processor_remove+0x96/0xc5 [processor] [<c024b991>] acpi_driver_detach+0x61/0xb7 [<c024bad3>] acpi_bus_unregister_driver+0x3a/0x90 [<d05c2018>] acpi_processor_exit+0x40/0x62 [processor] [<c012fa29>] sys_delete_module+0x119/0x170 [<c0145cde>] do_munmap+0x10e/0x150 [<c0145d61>] sys_munmap+0x41/0x70 [<c010722b>] syscall_call+0x7/0xb Unable to handle kernel paging request at virtual address d05bf3a5 printing eip: d05bf3a5 *pde = 0ac23067 *pte = 00000000 Oops: 0000 [#1] PREEMPT CPU: 0 EIP: 0060:[<d05bf3a5>] Not tainted EFLAGS: 00010202 (2.6.5-rc2) EIP is at 0xd05bf3a5 eax: 00a39718 ebx: 00001008 ecx: 00a38c98 edx: 00001008 esi: ced15174 edi: ced150c4 ebp: c0483fc8 esp: c0483fb0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0482000 task=c03f9a20) Stack: c0483fe0 ced150c4 00000001 d05bf2bb c0482000 00000000 c0483fe0 c01050ff c03a4db2 c0482000 00099100 c04a7b60 c0483ff8 c04847e6 c03a4b18 c0484540 c04a7b80 00000816 0051d007 c010019f Call Trace: [<c01050ff>] cpu_idle+0x4f/0x70 [<c04847e6>] start_kernel+0x146/0x170 [<c0484540>] unknown_bootoption+0x0/0x120 Code: Bad EIP value. <0>Kernel panic: Attempted to kill the idle task! In idle task - not syncing The reason is that the idle thread can be left [it's of higher priority as the idle thread] after a call to local_irq_enable() and before returning to cpu_idle(). The module unloads, but as soon as the system becomes idle again, the scheduler tries to continue the idle thread somewhere in the no longer existing acpi_processor_idle...
please check if the patch in Bug 1716 resolves your problem
Indeed, it's solved by the patch in bug 1716. However, the "patch for prevent sleeping in atomic area" is inacceptable, IMHO: the acpi_device_lock is taken around acpi_processor_remove for a reason, and dropping that lock within acpi_processor_remove breaks stuff seriosly -- and that's even more harmful than the sleep warning. *** This bug has been marked as a duplicate of 1716 ***