Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 Mar 2013 08:52:12 +0100
From:      Hans Petter Selasky <hps@bitfrost.no>
To:        Jung-uk Kim <jkim@freebsd.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: ACPI locking bugs?
Message-ID:  <6951816.YIytQN410a@laptop015.hselasky.homeunix.org>
In-Reply-To: <512E5E4C.807@FreeBSD.org>
References:  <201302271453.43985.hps@bitfrost.no> <512E5E4C.807@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 February 2013 14:28:12 Jung-uk Kim wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote:
> > Hi,
> > 
> > What is the reason for using cv_wait_sig() and cv_timedwait_sig()
> > instead of cv_wait() and cv_timedwait() inside of
> > AcpiOsWaitSemaphore(). What signals are supposed to be catched
> > here?
> > 
> > switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as,
> > Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while
> > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =
> > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error
> > == EINTR || as->as_reset) { status = AE_ERROR; break; } } break;
> > default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as,
> > Units)) { prevtick = ticks; as->as_waiters++; error =
> > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--;
> > if (error == EINTR || as->as_reset) { status = AE_ERROR; break; }
> > if (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if
> > (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -=
> > slptick; } }
> > 
> > I've observed an issue twice on my MacBookPro that some ACPI
> > locking fails during shutdown on 9-stable and then the power-off
> > won't complete. I've been unable to capture the full dmesg, because
> > syslogd is killed at the moment this happens. There are two ACPI
> > error printouts about failed locking.
> > 
> > I see that in the case of ACPI_WAIT_FOREVER, it appears to be
> > incorrect to catch signals, because sometimes the return argument
> > is not checked for lock operations:
> > 
> > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > 
> > Any comments?
> > 
> > Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore
> 
> I don't exactly remember why it was written like that, sorry.
> Probably it was to work around broken mutex uses in ACPICA at the time.
> 
> FYI, many ACPICA patches are contributed by Linux developers.
> Unfortunately, the Linux OS-dependent code does not implement the
> ACPICA OSL API fully and omits some corner cases. [1]
> 
> For example, ACPICA mutex is implemented via semaphore:
> 
> http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51
> http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239
> 
> And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER:
> 
> http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227
> 
> So, a lot of locking related ACPICA patches ignored these corner
> cases.  Another problem is that we are very serious about locking
> orders but ACPICA doesn't really care much because Linux and others
> don't care, really.
> 
> Another example is the ACPICA "cache" allocator.  It is actually
> modeled after Linux's slab allocator, i.e., kmem_cache_*():

Hi,

The problem is not locking or locking order, but that the locking wait for 
signals. You know when you have a thread, you kan kill it using a signal. I 
think at shutdown all threads and processes gets a KILL signal, and that 
confuses ACPICA if it is about to grab a mutex.

> http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636
> 
> Unfortunately, it doesn't really fit into our closest KPI, i.e.,
> zone(9). [2]
> 
> We always tried our best to *fully* implement OSL but it is not an
> easy task. :-(
> 
> Jung-uk Kim
> 
> 1.  For the official ACPICA OS-dependent API, please see "ACPI
> Component Architecture User Guide and Programmer Reference".  You can
> get it from here:
> 
> https://www.acpica.org/documentation/
> 
> 2.  There were some patches but I am not really comfortable with any
> of these patches yet.

--HPS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6951816.YIytQN410a>