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>