From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mtagate3.uk.ibm.com (mtagate3.uk.ibm.com [195.212.29.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mtagate3.uk.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 24301DDE3D for ; Tue, 11 Dec 2007 04:42:08 +1100 (EST) Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id lBAHg3Hp130976 for ; Mon, 10 Dec 2007 17:42:03 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lBAHg3Bb4948178 for ; Mon, 10 Dec 2007 17:42:03 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lBAHfkfd007042 for ; Mon, 10 Dec 2007 17:41:47 GMT From: Joachim Fenkes To: Roland Dreier Subject: Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5 Date: Mon, 10 Dec 2007 18:41:29 +0100 References: <200712061607.20004.fenkes@de.ibm.com> <200712071058.38416.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200712101841.30010.fenkes@de.ibm.com> Cc: Arnd Bergmann , LKML , OF-EWG , linuxppc-dev@ozlabs.org, Christoph Raisch , Marcus Eder , OF-General , Stefan Roscher List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Monday 10 December 2007 00:22, Roland Dreier wrote: > Fair enough... according to Documentation/infiniband/core_locking.txt, > the only driver methods that cannot sleep are: > > [...] > map_phys_fmr In fact, we do use hCalls there. Our hardware doesn't actually support FMRs, so we translate a "map FMR" into a "reallocate PMR", which doesn't work without hCalls. What's more, the hCalls involved (e.g. H_FREE_RESOURCE) might well return H_LONG_BUSY, so the whole operation might sleep; no way around it. How should we deal with this? Thanks, Joachim