From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 6 17:14:48 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD91BD22; Sat, 6 Apr 2013 17:14:48 +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 6F2C278D; Sat, 6 Apr 2013 17:14:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA04486; Sat, 06 Apr 2013 20:14:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UOWhR-0006CP-70; Sat, 06 Apr 2013 20:14:45 +0300 Message-ID: <51605804.8080906@FreeBSD.org> Date: Sat, 06 Apr 2013 20:14:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Baldwin Subject: Re: call suspend_cpus() under smp_ipi_mtx References: <5114AB2E.2050909@FreeBSD.org> <514D7A82.9000105@FreeBSD.org> <201304011052.18370.jhb@freebsd.org> <515DB988.1080100@FreeBSD.org> In-Reply-To: <515DB988.1080100@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, FreeBSD Current 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: Sat, 06 Apr 2013 17:14:48 -0000 on 04/04/2013 20:34 Andriy Gapon said the following: > This seems to work without problems or any warnings with WITNESS && > !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the > relevant code paths. > > P.S. Looking through history it seems that in r169391 intr_table_lock > was changed from a spinlock to a sx lock (later it was changed to the current > mutex). The commit message explains why spinlock was not needed, but it doesn't > seem to say why it was unacceptable: Hmm, looks like I missed the elephant. apic_free_vector is called with intr_table_lock held and it calls sched_bind(). I need to re-think all of think from the scratch... -- Andriy Gapon