From owner-freebsd-hackers@freebsd.org Tue Sep 11 17:39:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47E081097C84 for ; Tue, 11 Sep 2018 17:39:50 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C368580FA0 for ; Tue, 11 Sep 2018 17:39:49 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 33D6D3B9; Tue, 11 Sep 2018 13:39:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 11 Sep 2018 13:39:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=+qJFhsd4dNZnn0vZEFoyMedUDe2Ta /QHqsSSkKn6/TM=; b=kDlsb+D6EBDaQAZ0yaLMG4EtKTiHNWK5/uA2RbZDwt+Ep mLVfBmc9WTJtahJhB45nZAmfGkQ9N/5q178KXhdzVPeLb5uMsGwPHCQrKh7oZ/5P Fbb3vzck4UAZV4PLOPfO5SOAZTqBnB6XFrWGX1HkEjSHdMbqf/2npty+e2WKa2q+ 61ecJxA3SXJ00oPbBrRmOb7nWkkudgy2YGFwNY2TYho6Of2K/p4S7uuTcoezM89U /T5GIBo605Cjg5Jxvh681298yssGpomtd8KmDHhXDGcpGy8sRkqjRo7wHsnmZsic 4P1xkXm7qUxyHWkW41Ed0hhdum4iuIi71PiuOHvbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+qJFhs d4dNZnn0vZEFoyMedUDe2Ta/QHqsSSkKn6/TM=; b=cBcbFnMOwoXK0d5dsCYXhW vFWlXiJ7HjqlxqxXsKty53JDdjwgxaDVKXN6KZfGGXR2duPQAQltASSSljnxD0el xRIFp/ykiyo/ffT21nwIKkmq5JXnDvCnJXKHq8svwdj22RPNLrII2CGQJBGImm/D LA6709oJuaUaTKArhxJJxg2Rt40He3uzATtETu0+dCZheAzioQ3JRbqL8qhRczJp qoPGz0rR+YS33/1uj8TblJ7OcF81nj8XQitOeyq1Dh/WO0cSu+3D53Y9eWqyCUcz /5haYDd9l+QPzUwzfHUqwIaoklmrCVhe8JbeUNgq143TbcLJYF/fpNrL78SHz6Hw == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.113.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 306EFE41E6; Tue, 11 Sep 2018 13:39:46 -0400 (EDT) Subject: Re: ACPI GPE handler: mtx_lock() by idle thread To: Konstantin Belousov Cc: freebsd-hackers References: <475afc8c-d0ad-ead2-e75e-bca873977c2d@yuripv.net> <20180911084357.GU3161@kib.kiev.ua> From: Yuri Pankov Message-ID: <8affc553-3db8-fd7f-b8be-c04d1072b84c@yuripv.net> Date: Tue, 11 Sep 2018 20:39:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180911084357.GU3161@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 17:39:50 -0000 Konstantin Belousov wrote: > On Tue, Sep 11, 2018 at 08:19:26AM +0300, Yuri Pankov wrote: >> I have the panic shown below with a simple device driver that installs >> GPE handler in the attach routine, and does nothing else than waiting >> for GPEs. No matter if I try to handle it sync (calling >> SPIBUS_TRANSFER() from the handler), or async (calling >> taskqueue_enqueue()), once one of those functions called from the >> handler does mtx_lock(), it panics. Any hints? > If you look at the backtrace below, you would note that ACPI GPE event > handler is executed in the context of an interrupt. It means that it > borrows the context of whatever thread was executed on the CPU when the > interrupt occured. One of the consequences is that an interrupt handler > (fast interrupt handler in the FreeBSD terminology) cannot block or > sleep, see locking(9). > > There is a different way to handle interrupts in FreeBSD, by normal (not > fast) interrupt handlers. There, the code executing in the context of > interrupt only wakes up the interrupt thread, which executes the handler > in its dedicated context. As the consequence, mutexes do work for such > handlers. Still, sleep is prohibited. > > I briefly looked at the dev/intel/spi.c code and I see that > intelspi_transfer() sleeps waiting for the hardware event. In other > words, even normal interrupt handler cannot help your problem. > > Is it required to do the transfers in the interrupt handler code, for > your work ? If not, then the usual solution is to delegate the work > that requires resource acquision, to the fast taskqueue. Your code in > GPE event handler would only schedule a task, and the running task can > do whatever slow operations it needs. See taskqueue(9), there are > enough examples of the fast taskqueue use in the tree. Of course, I don't need to process the event in the GPE handler, and just noted that I tried to compare with taskqueue_enqueue()'d async handler, which produced the same results mainly because I was stupid and didn't notice that there's a separate predefined taskqueue for interrupt processing, taskqueue_fast. Now all looks good, I have the chance to do spi transfer in async handler. Thank you for all your help.