acpi interrupt storm when disabling, IPI hang

[Don Bowman]

When i run 'acpiconf -d', i get an interrupt storm on irq9...
vmstat -i shows ~1000/s.

Jun 15 13:41:33 cdata kernel: Interrupt storm detected on "irq9: acpi0";
throttling interrupt source

when i try to re-enable, i get an error:

# acpiconf -e
acpi0: interrupt handler already installed
    ACPI-0210: *** Error: Unable to install System Control Interrupt
Handler, AE_ALREADY_EXISTS
acpiconf: enable failed: Device not configured
# 

System is a Supermicro X5DPE motherboard, dual 2.8GHz Xeon,
533MHz FSB, Intel e7501 chipset.

# sysctl hw.acpi
hw.acpi.supported_sleep_state: S1 S4 S5 
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 0
hw.acpi.disable_on_poweroff: 0
hw.acpi.reset_video: 1
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 99%


The system will not boot 5.x if acpi is disabled.
It will run 4.x without trouble tho.

I am currently debugging a problem where 2
of the processors are in acpi_cpu_c1, 1 is
in idle, and 1 calls smp_tlb_shootdown, but
the IPI to one of the other processors never
completes, so it hangs. I have a core file
from this state.

(kgdb) printStack2 0xed09acdc
 <acpi_cpu_idle+129>:     0xa10cc483
 <cpu_idle+40>:   0xf689c3c9
 <idle_proc+25>:  0xe800768d
 <fork_exit+113>: 0xb808c483
 <fork_trampoline+8>:     0xe90cc483
(kgdb)  printStack2 0xed09dcd8
 <acpi_cpu_c1+5>: 0x5590c3c9
 <acpi_cpu_idle+193>:     0x0000d4e9
 <cpu_idle+40>:   0xf689c3c9
 <idle_proc+25>:  0xe800768d
 <fork_exit+113>: 0xb808c483
 <fork_trampoline+8>:     0xe90cc483
(kgdb)  printStack2 0xed0a0cd8
 <acpi_cpu_c1+5>: 0x5590c3c9
 <acpi_cpu_idle+193>:     0x0000d4e9
 <cpu_idle+40>:   0xf689c3c9
 <idle_proc+25>:  0xe800768d
 <fork_exit+113>: 0xb808c483
 <fork_trampoline+8>:     0xe90cc483

(kgdb)  printStack2 0xeec7dc3c
 <cluster_callback+43>:   0x0128978b
 <bufdone+275>:   0x000350e9
 <bufdonebio+63>: 0x6404c483
 <biodone+134>:   0x8d04c483
 <g_dev_done+91>: 0x5bf8658d
 <biodone+134>:   0x8d04c483
 <g_io_schedule_up+218>:  0xc483f689
 <g_up_procbody+26>:      0xeb04c483
 <fork_exit+113>: 0xb808c483
 <fork_trampoline+8>:     0xe90cc483

Sometimes that last one is like:

#7  0xc068e066 in smp_tlb_shootdown (vector=246, addr1=0, addr2=0)
    at machine/cpufunc.h:305
#8  0xc068e1d0 in smp_invlpg_range (addr1=3876638720, addr2=3876769792)
    at /usr/src/sys/i386/i386/mp_machdep.c:1030
#9  0xc0690643 in pmap_invalidate_range (pmap=0xc077dd80, sva=3876638720, 
    eva=3876769792) at /usr/src/sys/i386/i386/pmap.c:640
#10 0xc0690be0 in pmap_qenter (sva=3876638720, m=0xde548600, count=0)
    at /usr/src/sys/i386/i386/pmap.c:958
#11 0xc058aca3 in cluster_rbuild (vp=0xc83db104, filesize=1073741824, 
    lbn=40844, blkno=241691456, size=16384, run=8, fbp=0x0)
    at /usr/src/sys/kern/vfs_cluster.c:508
#12 0xc058a3a8 in cluster_read (vp=0xc83db104, filesize=1073741824, 
    lblkno=40844, size=16384, cred=0x0, totread=8192, seqcount=127, bpp=0x0)
    at /usr/src/sys/kern/vfs_cluster.c:263
#13 0xc063dc4a in ffs_read (ap=0x0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:441
#14 0xc059e325 in vn_read (fp=0xc5a02198, uio=0xf53c1c88, 
    active_cred=0xc59f6280, flags=0, td=0xc6645e70) at vnode_if.h:398
#15 0xc05655bc in dofileread (td=0xc6645e70, fp=0xc5a02198, fd=23, 
    buf=0x706b40c0, nbyte=8192, offset=0, flags=0)
    at /usr/src/sys/sys/file.h:233
#16 0xc0565467 in read (td=0xc6645e70, uap=0xf53c1d14)
    at /usr/src/sys/kern/sys_generic.c:107
#17 0xc06956f7 in syscall (frame=
      {tf_fs = 138149935, tf_es = 138149935, tf_ds = -1078001617, tf_edi =
81682, tf_esi = 137404728, tf_ebp = -1077946040, tf_isp = -180609676, tf_ebx
= 608, tf_edx = 23, tf_ecx = 137834496, tf_eax = 3, tf_trapno = 22, tf_err =
2, tf_eip = 1749868123, tf_cs = 31, tf_eflags = 582, tf_esp = -1077946068,
tf_ss = 47})
    at /usr/src/sys/i386/i386/trap.c:1004
#18 0x684cde5b in ?? ()


(kgdb) disass acpi_cpu_c1
Dump of assembler code for function acpi_cpu_c1:
0xc084cc44 <acpi_cpu_c1>:       push   %ebp
0xc084cc45 <acpi_cpu_c1+1>:     mov    %esp,%ebp
0xc084cc47 <acpi_cpu_c1+3>:     sti    
0xc084cc48 <acpi_cpu_c1+4>:     hlt    
0xc084cc49 <acpi_cpu_c1+5>:     leave  
0xc084cc4a <acpi_cpu_c1+6>:     ret    
0xc084cc4b <acpi_cpu_c1+7>:     nop    
End of assembler dump.


(kgdb) disass acpi_cpu_idle
Dump of assembler code for function acpi_cpu_idle:
0xc084caa0 <acpi_cpu_idle>:     push   %ebp
 ...
0xc084cb4f <acpi_cpu_idle+175>: cltd   
0xc084cb50 <acpi_cpu_idle+176>: idivl  0xc0753f0c
0xc084cb56 <acpi_cpu_idle+182>: mov    %eax,0x9c(%esi)
0xc084cb5c <acpi_cpu_idle+188>: call   0xc084cc44 <acpi_cpu_c1>
0xc084cb61 <acpi_cpu_idle+193>: jmp    0xc084cc3a <acpi_cpu_idle+410>
0xc084cb66 <acpi_cpu_idle+198>: mov    %esi,%esi
0xc084cb68 <acpi_cpu_idle+200>: cmpl   $0x3,0x4(%edi)
0xc084cb6c <acpi_cpu_idle+204>: jne    0xc084cb88 <acpi_cpu_idle+232>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.boot
Type: application/octet-stream
Size: 8280 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20040615/2ab8b149/dmesg.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cdata.asl.gz
Type: application/octet-stream
Size: 10931 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20040615/2ab8b149/cdata.asl.obj