From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 14:55:00 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73221E04 for ; Wed, 27 Feb 2013 14:55:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AFDDB7EA for ; Wed, 27 Feb 2013 14:54:56 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16272; Wed, 27 Feb 2013 16:54:53 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <512E1E3D.7090501@FreeBSD.org> Date: Wed, 27 Feb 2013 16:54:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ACPI locking bugs? References: <201302271453.43985.hps@bitfrost.no> In-Reply-To: <201302271453.43985.hps@bitfrost.no> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:55:00 -0000 on 27/02/2013 15:53 Hans Petter Selasky said the following: > 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? kib drew my attention to this issue some time ago and I also pinged jkim about it. I completely agree with you that the signal handling should be removed. Are you willing to make the change or would you prefer me doing it? Thank you. -- Andriy Gapon