Bug 2350

Summary:	rmmod processor.ko can panic() if CONFIG_PREEMPT is enabled
Product:	ACPI	Reporter:	Dominik Brodowski (linux)
Component:	Power-Processor	Assignee:	acpi_power-processor
Status:	CLOSED DUPLICATE
Severity:	normal
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.5-rc2	Subsystem:
Regression:	---	Bisected commit-id:

Description Dominik Brodowski 2004-03-22 01:11:28 UTC

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...

Comment 1 Shaohua 2004-03-24 16:40:29 UTC

please check if the patch in Bug 1716 resolves your problem

Comment 2 Dominik Brodowski 2004-03-26 00:56:30 UTC

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 ***