From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5BC03C43218 for ; Tue, 11 Jun 2019 05:58:35 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A5E9220679 for ; Tue, 11 Jun 2019 05:58:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5E9220679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45NK7D381fzDqV4 for ; Tue, 11 Jun 2019 15:58:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=permerror (mailfrom) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=benh@kernel.crashing.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45NK5F12XgzDqRs for ; Tue, 11 Jun 2019 15:56:48 +1000 (AEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x5B5uXlu029265; Tue, 11 Jun 2019 00:56:34 -0500 Message-ID: Subject: Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook From: Benjamin Herrenschmidt To: Larry Finger , Aaro Koskinen , Christoph Hellwig , Christian Zigotzky , Michael Ellerman Date: Tue, 11 Jun 2019 15:56:33 +1000 In-Reply-To: <3ed1ccfe-d7ca-11b9-17b3-303d1ae1bb0f@lwfinger.net> References: <20190605225059.GA9953@darkstar.musicnaut.iki.fi> <73da300c-871c-77ac-8a3a-deac226743ef@lwfinger.net> <7697a9d10777b28ae79fdffdde6d0985555f6310.camel@kernel.crashing.org> <3ed1ccfe-d7ca-11b9-17b3-303d1ae1bb0f@lwfinger.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-wireless@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, 2019-06-10 at 13:44 -0500, Larry Finger wrote: > On 6/7/19 11:21 PM, Benjamin Herrenschmidt wrote: > > > > > Please try the attached patch. I'm not really pleased with it and I will > > > continue to determine why the fallback to a 30-bit mask fails, but at least this > > > one works for me. > > > > Your patch only makes sense if the device is indeed capable of > > addressing 31-bits. > > > > So either the driver is buggy and asks for a too small mask in which > > case your patch is ok, or it's not and you're just going to cause all > > sort of interesting random problems including possible memory > > corruption. > > Of course the driver may be buggy, but it asks for the correct mask. > > This particular device is not capable of handling 32-bit DMA. The driver detects > the 32-bit failure and falls back to 30 bits. It works on x86, and did on PPC32 > until 5.1. As Christoph said, it should always be possible to use fewer bits > than the maximum. No, I don't think it *worked* on ppc32 before Christoph patch. I think it "mostly sort-of worked" :-) The reason I'm saying that is if your system has more than 1GB of RAM, then you'll have chunks of memory that the device simply cannot address. Before Christoph patches, we had no ZONE_DMA or ZONE_DMA32 covering the 30-bit limited space, so any memory allocation could in theory land above 30-bits, causing all sort of horrible things to happen with that driver. The reason I think it sort-of-mostly-worked is that to get more than 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network buffers aren't allocated in Highmem.... so you got lucky. That said, there is such as thing as no-copy send on network, so I wouldn't be surprised if some things would still have failed, just not frequent enough for you to notice. > Similar devices that are new enough to use b43 rather than b43legacy work with > new kernels; however, they have and use 32-bit DMA. Cheres, Ben.