Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7706984ybi; Wed, 5 Jun 2019 23:42:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqwR/vN1WRQ+hgi9VCqjuxA0kmeKZcZEg8AO54FSUjZs+7SgPGQGx8kPVIrKJyxp1Ke1of1Q X-Received: by 2002:a17:902:9f93:: with SMTP id g19mr33571537plq.223.1559803323771; Wed, 05 Jun 2019 23:42:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559803323; cv=none; d=google.com; s=arc-20160816; b=CuZc5hLRy4UjOzhRJnjZByjuudlqc6MbUWTJfAIVP+W/hxLjeS/QvT42MoiwSFA4v3 fe/SWtG6SUvXGDWbJWVxeb8sPtir+HDRt6P8fGdLsYkqBpl81WgmLG5UebDFg8HTwKhN tABlqWq2WnVxvfCak0vD64Xi/G8Sbzt2dHKktfeoF5o8jkBQBzt3YWweh+R5noXRu2re 9ET+kK1ovtsdqAI2A4aWHJwyIOXYifYcT4F/+fi0jLo+pYfmDgaubqHKNFG08CSpVD/V 968M35KhH7d0Q0Ug5tlYfk1o/TtgpzRtSiQFl5TbJk5luoyss3qt/AlpBT/lNo0l2ANF Rx6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ExYTbnta6qxyg+yi857EJ61PiKDPKneEXFhwq+TxC6Q=; b=0XhznWA/EQDhRLrbgYJY8wyKp6dvd3Mp48PP+3Va1uteFYlgpAUFUVQqBS5syIGcQb 5EGVgzFmedUPp2mDO+7zmD+7Tb7MQ2gcF12FozJtztV1a8xJjX6GGs4GCNRFfwGL110c 8uB/UICgXxFk9pxNkhUbd/29MEphLffCIlaWYQZPtWfHK7stIOogGKV85RfVCbc7vhCf ujMwbeiqfPKqFqRi3+DuvPW3fwAXwLFYqj4qgtcWQxryohtQbgHcQAno4UV0L6v2nbNm HWT5n9aktqM0nRZyZnnNDMK4T5WrR7nGIr7jqGTNdYBOJjySaiVodtnBg8SKBeJzZvLt d/MA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f64si975379plf.128.2019.06.05.23.41.47; Wed, 05 Jun 2019 23:42:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726294AbfFFGkn (ORCPT + 99 others); Thu, 6 Jun 2019 02:40:43 -0400 Received: from verein.lst.de ([213.95.11.211]:47405 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725267AbfFFGkn (ORCPT ); Thu, 6 Jun 2019 02:40:43 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id CEE9668B05; Thu, 6 Jun 2019 08:40:15 +0200 (CEST) Date: Thu, 6 Jun 2019 08:40:15 +0200 From: Christoph Hellwig To: Larry Finger Cc: Aaro Koskinen , Christoph Hellwig , Christian Zigotzky , Michael Ellerman , linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook Message-ID: <20190606064015.GC27033@lst.de> References: <20190605225059.GA9953@darkstar.musicnaut.iki.fi> <35b3f09b-b371-e2cc-4436-120c67e2f1fb@lwfinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35b3f09b-b371-e2cc-4436-120c67e2f1fb@lwfinger.net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 05, 2019 at 10:06:18PM -0500, Larry Finger wrote: > First of all, you have my sympathy for the laborious bisection on a > PowerBook G4. I have done several myself. Thank you. > > I confirm your results. > > The ppc code has a maximum DMA size of 31 bits, thus a 32-bit request will > fail. Why the 30-bit fallback fails in b43legacy fails while it works in > b43 is a mystery. > > Although dma_nommu_dma_supported() may be "largely identical" to > dma_direct_supported(), they obviously differ. Routine > dma_nommu_dma_supported() returns 1 for 32-bit systems, but I do not know > what dma_direct_supported() returns. > > I am trying to find a patch. if (IS_ENABLED(CONFIG_ZONE_DMA)) min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS); else min_mask = DMA_BIT_MASK(32); min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT); return mask >= __phys_to_dma(dev, min_mask); So the smaller or: (1) 32-bit (2) ARCH_ZONE_DMA_BITS (3) the actual amount of memory in the system modolo any DMA offsets that come into play. No offsets should exists on pmac, and ARCH_ZONE_DMA_BITS is 31 on powerpc. So unless the system has 1GB or less memory it will probably return false for b43, because it can't actually guarantee reliable allocation. It will work fine on x86 with the smaller ZONE_DMA.