Re: [issue531] ACPI bugs on Intel motherboards

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Mon, Jan 22, 2007 at 10:59:06PM -0000, eugene wrote:
> Here is the output of "trace":
> lwkt_sendmsg(10,c810bee0,c18af23c,ccbfccc4) at lwkt_sendmsg+0x4a
               ~~
> AcpiOsExecute(2,c0736ab7,c18af23c,102f,0) at AcpiOsExecute+0x6f
> AcpiEvGpeDispatch(c18af23,1d,c1706b15,3,0) at AcpiEvGpeDispatch+0x11f
> AcpiEvGpeDetect(c15a1940,c0614550,ccbfcd1c,c0758a25,c15a1940) at
> AcpiEvGpeDetect+0xd7
> AcpiEvSciXruptHandler(c15a1940,0,ccbfcd84,c02b21d9,c15a1940) at
> AcpiEvSciXruptHandler+0x19
> InterruptWrapper(c15a1940,0,0,0,1) at InterruptWrapper+0x2b
> ithread_handler(9,0,0,0,0) at ithread_handler+0x9d
> lwkt_exit() at lwkt_exit
> db>

Looks to me like acpi_task_thread is used (via AcpiOsExecute())
before the msgport is initialized, but it shouldn't happen since
most part of acpi_attach() is protected by critical section, which
suspends the interrupt.  This is just a shot in the dark, but I wonder
what happens if you move up the call to acpi_task_thread_init()
before the call to AcpiEnableSubsystem(), which installs the interrupt
handler called above (patch attached)?

Cheers.

Index: acpi.c
===================================================================
RCS file: /home/source/dragonfly/cvs/src/sys/dev/acpica5/acpi.c,v
retrieving revision 1.28
diff -u -p -r1.28 acpi.c
--- acpi.c	17 Jan 2007 17:31:19 -0000	1.28
+++ acpi.c	22 Jan 2007 23:56:08 -0000
@@ -429,6 +429,9 @@ acpi_attach(device_t dev)
     sc->acpi_dev = dev;
     callout_init(&sc->acpi_sleep_timer);
 
+    if ((error = acpi_task_thread_init()))
+	goto out;
+
     /*
      * Set the globals from our tunables.  This is needed because ACPI-CA
      * uses UINT8 for some values and we have no tunable_byte.
@@ -658,9 +661,6 @@ acpi_attach(device_t dev)
     }
 #endif
 
-    if ((error = acpi_task_thread_init()))
-	goto out;
-
     if ((error = acpi_machdep_init(dev)))
 	goto out;