Bug 2349

acpi_processor_idle() crassh -- moving but to ACPI sub-system

Len, please re-read the description: I only used the acpi idle handler as an
example, and advertedly added a division by zero to _prove_ that there's a
different(!) BUG: whenever an OOPS occurs in the idle handler, a panic() should
occur and lock the system. The panic() call is done, but the system is usable
afterwards. It's a process management bug, and not an ACPI bug.

How is it working now, with recent kernels? Isn't there a flag that tells whether to panic on oops?
Thanks.

When using the kernel 2.6.20, this bug is not reproduced. I changed the code of the arch/i386/kernel/process.c file as follows: 

diff -u arch/i386/kernel/process.c.orig arch/i386/kernel/process.c
--- arch/i386/kernel/process.c.orig     2007-10-12 00:22:38.000000000 +0400
+++ arch/i386/kernel/process.c  2007-10-12 00:19:55.000000000 +0400
@@ -94,12 +94,25 @@

 EXPORT_SYMBOL(enable_hlt);

+int codedot_oops = 0;
+EXPORT_SYMBOL(codedot_oops);
+
 /*
  * We use this if we don't have any better
  * idle routine..
  */
 void default_idle(void)
 {
+       volatile struct s {
+               int s;
+       } *s = NULL;
+
+       if (codedot_oops) {
+               codedot_oops = 0;
+               printk(KERN_EMERG "I am going to crash\n");
+               ++s->s;
+       }
+
        if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
                current_thread_info()->status &= ~TS_POLLING;
                /*

After the kernel has booted, I installed my own module, which switches the codedot_oops flag on. The kernel immediately reported an oops and a panic:

debian:~/oops# insmod oops.ko
[   77.012000] Oops module is being installed
debian:~/oops# [   77.054000] I am going to crash
[   77.056000] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
[   77.056000]  printing eip:
[   77.057000] c0101915
[   77.057000] *pde = 00000000
[   77.057000] Oops: 0000 [#1]
[   77.057000] PREEMPT
[   77.057000] Modules linked in: oops
[   77.057000] CPU:    0
[   77.057000] EIP:    0060:[<c0101915>]    Not tainted VLI
[   77.057000] EFLAGS: 00000282   (2.6.20 #8)
[   77.057000] EIP is at default_idle+0x35/0x70
[   77.057000] eax: 00000026   ebx: 00000800   ecx: c02eb420   edx: c02eb420
[   77.057000] esi: 00099100   edi: c02ff000   ebp: 0036a007   esp: c0305fe0
[   77.057000] ds: 007b   es: 007b   ss: 0068
[   77.057000] Process swapper (pid: 0, ti=c0304000 task=c02e7380 task.ti=c0304000)
[   77.057000] Stack: c02b90d8 c010119a c0306720 c02b6fe6 c0306250 00000000 c032cc40 00000000
[   77.057000] Call Trace:
[   77.057000]  [<c010119a>] cpu_idle+0x3a/0x70
[   77.057000]  [<c0306720>] start_kernel+0x280/0x300
[   77.057000]  [<c0306250>] unknown_bootoption+0x0/0x250
[   77.057000]  =======================
[   77.057000] Code: 75 16 a1 2c ca 32 c0 85 c0 75 09 80 3d 05 1f 30 c0 00 75 24 f3 90 58 c3 31 c0 a3 24 ca 32 c0 c7 04 24 d8 90 2b c0 e8 eb 37 01 00 <a1> 00 00 00 00 40 a3 00 00 00 00 eb ca 89 e0 25 00 e0 ff ff 83
[   77.057000] EIP: [<c0101915>] default_idle+0x35/0x70 SS:ESP 0068:c0305fe0
[   77.057000]  <0>Kernel panic - not syncing: Attempted to kill the idle task!
[   77.059000]

The system got freezed after that.

Can this bug be closed already?

Thanks Anton. This is definitely a proof we can close this bug now.