Re: ACPI-CA update patch for review

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Tue, Jan 09, 2007 at 10:33:35PM +0100, Simon 'corecode' Schubert wrote:
> YONETANI Tomokazu wrote:
> >B. using just spinlocks ended up in a panic when waking up from S3:
> >   still holding 1 exclusive spinlocks!
> >   (so I thought I can't use spinlock)
> 
> Heh!  I can actually sleep and wakeup now!  Of course, there is this panic 
> :)
> 
> It is due to holding -1 exclusive spinlocks, though.  I wonder how this 
> calculation can happen.

There's this piece of code in acpi_SetSleepState():

   if (state != ACPI_STATE_S1) {
       acpi_sleep_machdep(sc, state);

       /* AcpiEnterSleepState() may be incomplete, unlock if locked. */
       AcpiOsReleaseLock(AcpiGbl_HardwareLock, 1);

    /* Re-enable ACPI hardware on wakeup from sleep state 4. */
    if (state == ACPI_STATE_S4)

Previously AcpiOsReleaseLock() above was AcpiUtReleaseMutex(), and it's
been there because acpi_sleep_machdep() sometimes leaves hardware mutex
locked and sometimes not.  That still applies to the patched code, and
you have to unlock the spinlock only if it's locked here.  This doesn't
appear to be the right thing to do, and in fact it's been removed
in revision 1.179 of acpi.c in FreeBSD(actual commit log is in 1.180).