Fix global lock recursion bug.

This patch was part of ACPI-CA 20070508 release and the
following is excerpt from its change log:

Fixed a problem where the Global Lock handle was not properly
updated if a thread that acquired the Global Lock via executing
AML code then attempted to acquire the lock via the
AcpiAcquireGlobalLock interface. Reported by Joe Liu.

Approved by:	re (kensmith)
Tested by:	ambrisko
Obtained from:	Intel

sys/contrib/dev/acpica/evmisc.c

@@ -567,6 +567,20 @@ AcpiEvAcquireGlobalLock (
         return_ACPI_STATUS (Status);
     }
 
+    /*
+     * Update the global lock handle and check for wraparound. The handle is
+     * only used for the external global lock interfaces, but it is updated
+     * here to properly handle the case where a single thread may acquire the
+     * lock via both the AML and the AcpiAcquireGlobalLock interfaces. The
+     * handle is therefore updated on the first acquire from a given thread
+     * regardless of where the acquisition request originated.
+     */
+    AcpiGbl_GlobalLockHandle++;
+    if (AcpiGbl_GlobalLockHandle == 0)
+    {
+        AcpiGbl_GlobalLockHandle = 1;
+    }
+
     /*
      * Make sure that a global lock actually exists. If not, just treat
      * the lock as a standard mutex.

sys/contrib/dev/acpica/evxface.c

@@ -921,16 +921,7 @@ AcpiAcquireGlobalLock (
 
     if (ACPI_SUCCESS (Status))
     {
-        /*
-         * If this was the first acquisition of the Global Lock by this thread,
-         * create a new handle. Otherwise, return the existing handle.
-         */
-        if (AcpiGbl_GlobalLockMutex->Mutex.AcquisitionDepth == 1)
-        {
-            AcpiGbl_GlobalLockHandle++;
-        }
-
-        /* Return the global lock handle */
+        /* Return the global lock handle (updated in AcpiEvAcquireGlobalLock) */
 
         *Handle = AcpiGbl_GlobalLockHandle;
     }