Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3077270ybc; Mon, 25 Nov 2019 08:39:36 -0800 (PST) X-Google-Smtp-Source: APXvYqzV6uTevUsuIBG431+ba17OGn2KEAIvYov3bLpFDpNWViGScO8QeiFgjFboSRiCeJ76C2ys X-Received: by 2002:a17:906:a40e:: with SMTP id l14mr38037669ejz.168.1574699976425; Mon, 25 Nov 2019 08:39:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574699976; cv=none; d=google.com; s=arc-20160816; b=qIJSWj+FOR+B3N0OySLldiQu4GhTzYG5uR63wrdZymIG54aI6vQmydAGJ2yQ21GarY 5PrORmrcS2RHitr0sMtjrQBc163X9x6IclQ9jqunH0/Q0eNjWWEUk090zxkyPOZG87d6 eW2Latw/2IqvQELXCugEI+3OuY7zeaA7yKR9I2/vpfbFE5CCLtXypvTabScXObu886MH HWH8HxOJani4Hfm15Z2W4nSYTjefXQ0v/iJaZrOrNzjR2OLDubp1/qGHwivciRsZjPG4 gIRSVZ8fKB5+SWCl1YRYPWa8MlnBwn9kVMFJAj09Ivzeh+Q26L1i9A92OD2L776jmEwz meZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=7k/spbSE4Wnjsqc+UF1NKqt47ly0JC/Mr6Ef3iOR2Sc=; b=awsoGvhSRg04PdMDrYLvOGhbTX9HgeyYxFYE3xLiAzmRLw5hZHPz+WxlxR0rmPOFGc Qv0eiDfFGvEjQH3SE3xyo7g4af5k0H4I5EIqnLSOmV7DK7j3RUOtiMu4r52Jd7MgJ7md t8l0DLJGZYFM2gi+eErtKrP8YDgpiLB0+M/Vxo3iQ8LLROijT76eeDg/9G39DyzSR0rF 2+NEsANB/8eZNSUE5xdjx5L9t+HwrvFRz4F/eOkHV23PM0mKvAq1GYhzaVGUOWiDllbc M2M/bPLAuXmdfc91ds7SpBZUFktBL0tTMFZ7CklAVjrJFLT2w4/YJdwUXSkyXHx2iHTB DtjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@xenosoft.de header.s=strato-dkim-0002 header.b=V+zZ2g58; 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 t11si4783135eju.106.2019.11.25.08.39.12; Mon, 25 Nov 2019 08:39:36 -0800 (PST) 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; dkim=fail header.i=@xenosoft.de header.s=strato-dkim-0002 header.b=V+zZ2g58; 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 S1728951AbfKYQgc (ORCPT + 99 others); Mon, 25 Nov 2019 11:36:32 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.80]:12407 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728940AbfKYQga (ORCPT ); Mon, 25 Nov 2019 11:36:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1574699788; s=strato-dkim-0002; d=xenosoft.de; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=7k/spbSE4Wnjsqc+UF1NKqt47ly0JC/Mr6Ef3iOR2Sc=; b=V+zZ2g58uFy1XfbG736YCiQ6k+2ro5Vd+0R8Gaqjq5HiWNQNq9d2aT/srkOAr3uba/ 8DQfuSmrsEAEqAVLcAt7Lu6qEb88UC/b3M37NJF5t7hAUdvLi2GuUZL4OyWnGM8iNH+/ NBv3yFTOnzFBNe98tykKKycr3oZnhZxizzkGIAUUSPQ3vthXLdIdJFUWRyjrhYBN58G7 9Syyyll18biZwBsoP2u+p5oXdWYWNXkJuWau9JlSiCk/f2hOKsFtpAaciEyM1E1RtuqK z7xtxWeQO7qpFk1nGM+RMjBmrMEC91ZjGxjrVhMxnO0Pf5+waznjcy20IBPB312Oh4ar bsIg== X-RZG-AUTH: ":L2QefEenb+UdBJSdRCXu93KJ1bmSGnhMdmOod1DhGM4l4Hio94KKxRySfLxnHfJ+Dkjp5DdBJSrwuuqxvPhXJixqXRlXNgnQNtnHeat+VHo=" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2a02:8109:89c0:ebfc:40cb:202:5c2:453d] by smtp.strato.de (RZmta 45.0.2 AUTH) with ESMTPSA id x0678cvAPGaH2b4 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 25 Nov 2019 17:36:17 +0100 (CET) Subject: Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M To: Christoph Hellwig Cc: Robin Murphy , linux-arch@vger.kernel.org, darren@stevens-zone.net, mad skateman , Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Rob Herring , paulus@samba.org, rtd2@xtra.co.nz, "contact@a-eon.com" , linuxppc-dev , nsaenzjulienne@suse.de, Mike Rapoport References: <20191121072943.GA24024@lst.de> <6eec5c42-019c-a988-fc2a-cb804194683d@xenosoft.de> <20191121180226.GA3852@lst.de> <2fde79cf-875f-94e6-4a1b-f73ebb2e2c32@xenosoft.de> <20191125073923.GA30168@lst.de> From: Christian Zigotzky Message-ID: <96537365-8dbf-7f7e-f37f-14bf5c144b45@xenosoft.de> Date: Mon, 25 Nov 2019 17:36:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191125073923.GA30168@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: de-DE Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25 November 2019 at 08:39 am, Christoph Hellwig wrote: > On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: >> Hello Christoph, >> >> Please find attached the dmesg of your Git kernel. > Thanks. It looks like on your platform the swiotlb buffer isn't > actually addressable based on the bus dma mask limit, which is rather > interesting. swiotlb_init uses memblock_alloc_low to allocate the > buffer, and I'll need some help from Mike and the powerpc maintainers > to figure out how that select where to allocate the buffer from, and > how we can move it to a lower address. My gut feeling would be to try > to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably > without needing too much arch specific magic. > > As a quick hack can you try this patch on top of the tree from Friday? > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > index f491690d54c6..e3f95c362922 100644 > --- a/include/linux/memblock.h > +++ b/include/linux/memblock.h > @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) > #define MEMBLOCK_LOW_LIMIT 0 > > #ifndef ARCH_LOW_ADDRESS_LIMIT > -#define ARCH_LOW_ADDRESS_LIMIT 0xffffffffUL > +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL > #endif > > phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, > Hello Christoph, Thanks a lot for your help! I will test your patch tomorrow. Cheers, Christian