From patchwork Thu Oct 12 09:13:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Dirk Behme X-Patchwork-Id: 10001273 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 210AC602BF for ; Thu, 12 Oct 2017 09:13:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 13FEE28D34 for ; Thu, 12 Oct 2017 09:13:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 08EB428D36; Thu, 12 Oct 2017 09:13:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E83D928D34 for ; Thu, 12 Oct 2017 09:13:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751932AbdJLJNM (ORCPT ); Thu, 12 Oct 2017 05:13:12 -0400 Received: from smtp6-v.fe.bosch.de ([139.15.237.11]:49026 "EHLO smtp6-v.fe.bosch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbdJLJNM (ORCPT ); Thu, 12 Oct 2017 05:13:12 -0400 Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta23.fe.bosch.de (Postfix) with ESMTP id A17F315801DC; Thu, 12 Oct 2017 11:11:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=de.bosch.com; s=2015-01-21; t=1507799512; bh=etis1RzWD2sH1EyJ5iSEe/gmrkXW7rlWbFsE5ewHi68=; l=10; h=From:From:Reply-To:Sender; b=vimPeRfVQ4j35VPtq/uWFtmuyGwwwQ3PJtJqtXw5d6uXnFQBTBi5f6MmFrR56LllZ HzvqDa+SoTIPUptyeQ6lxkGEB4+xSbptNszlv4gvsm5K+DZZMrMj+AEClC1S0HCvK+ stZ9jdmme9OQ3CQrxVe2AvsBRz/9ngi3AN+II7QE= Received: from SI-HUB1001.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id A888F1B8042D; Thu, 12 Oct 2017 11:13:10 +0200 (CEST) Received: from [10.34.217.142] (10.34.217.142) by SI-HUB1001.de.bosch.com (10.4.103.108) with Microsoft SMTP Server id 14.3.319.2; Thu, 12 Oct 2017 11:13:09 +0200 Subject: Re: mainline 4.14-rc4: renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full? To: Geert Uytterhoeven CC: Linux-Renesas References: <50d1a9ac-fe5f-d0a1-62bc-ff3e252e99da@de.bosch.com> <5ccf4c75-6dd5-0818-54de-2a99a786a5c4@de.bosch.com> From: Dirk Behme Organization: Robert Bosch Car Multimedia GmbH Message-ID: Date: Thu, 12 Oct 2017 11:13:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5ccf4c75-6dd5-0818-54de-2a99a786a5c4@de.bosch.com> Content-Language: en-US X-Originating-IP: [10.34.217.142] X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-23386.005 X-TMASE-MatchedRID: vEvJ7Rh1lGgOwH4pD14DsPHkpkyUphL9uPSKAaI54qF+bUTCaUVYBIMT XtFtZLzB39+HS+ZX2EdUwgFxOdlY8xKAz9SPYPtnSEQN/D/3cG5Rpe71pI4bhRxUkJPe1WBqoqW jVsN2Etqz5Tm2We5VM63EhJSA9X7Xv94QsDvR6Nz0hv/rD7WVZEaFZr06XLdf3okhyh6eg2UgRP lrGC5FrzzIYciYTdEA+zNlxKXrPTY9d1nHWxkekC1Hx9UxMGjd3bCSO6/nk84Nht78/JfyBEDNo gBw28Ksi6BY6TGydtcnywL90zvWqRXfDcvxC40QF6z9HGHKwNv4uJ1REX4MHX5h6y4KCSJcPuM/ JIgdDxS/Xam5t+TFYkPUsRAlOmoAJYTzo6oWO/DKl4yJoI+fG30tCKdnhB581B0Hk1Q1KyLUZxE AlFPo846HM5rqDwqtlExlQIQeRG0= Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 12.10.2017 10:20, Dirk Behme wrote: > On 11.10.2017 15:20, Geert Uytterhoeven wrote: >> Hi Dirk, >> >> On Wed, Oct 11, 2017 at 2:57 PM, Dirk Behme >> wrote: >>> On 11.10.2017 14:42, Geert Uytterhoeven wrote: >>>> On Wed, Oct 11, 2017 at 2:23 PM, Dirk Behme >>>> wrote: >>>>> trying to boot recent mainline v4.14-rc4 on a custom H3 ES2.0 board >>>>> with >>>>> rootfs on SD card I'm getting [1]. >>>>> >>>>> Last time I think I used v4.13 in the same environment and I think it >>>>> worked >>>>> fine, most probably because renesas_sdhi_internal_dmac wasn't >>>>> there, yet >>>>> ;) >>>>> >>>>> I checked renesas-drivers-2017-10-03-v4.14-rc3 if there is anything >>>>> newer >>>>> regarding drivers/mmc/host/renesas_sdhi_internal_dmac.c but doesn't >>>>> look >>>>> so. >>>>> >>>>> Any idea what I missed? >>>>> >>>> How much swiotlb memory do you have? The default is 64 MiB: >>>> >>>>       software IO TLB [mem 0x77fff000-0x7bfff000] (64MB) mapped at >>>> [ffffffc037fff000-ffffffc03bffefff] >>> >>> Same here: >> >> OK. >> >>>> Then, who else is consuming lots of swiotlb memory? >> >> Or, not freeing allocated memory. >> >>> Hmm, any idea how to find that? >>> >>> The dmesg doesn't seem to have more infos about that (?) >> >> I'm afraid you have to add some prints to swiotlb_tbl_map_single() >> (and swiotlb_tbl_unmap_single())... > > > With [1] I'm getting [2]. What doesn't look that bad, at least quite > symmetric. Having a quick look I can't find any obvious not freed mem. > Hmm ... Ok, it seems to be somehow easy ;) It seems that the 524288 bytes them self are the issue, independent on the usage of the swiotlb memory. Doing a hack like [3], i.e. trying to map 524288 bytes at the first access, already, crashes, too [4]. So seems we have two issues? a) swiotlb_tbl_map_single() can't handle 524288 bytes and b) failing swiotlb_tbl_map_single() results in a kernel crash Now, I'm not sure whom to address both to? Is it an issue of renesas_sdhi_internal_dmac() which shouldn't call swiotlb with 524288 bytes? Or is this an error of swiotlb? Same for the kernel crash. Best regards Dirk [3] + mask = dma_get_seg_boundary(hwdev); tbl_dma_addr &= mask; [4] renesas_sdhi_internal_dmac ee100000.sd: swiotlb_tbl_map_single: trying to map 8 bytes renesas_sdhi_internal_dmac ee100000.sd: swiotlb_tbl_map_single: test: size modified to 524288 bytes renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full (sz: 524288 bytes) renesas_sdhi_internal_dmac ee100000.sd: DMA: Out of SW-IOMMU space for 8 bytes Unable to handle kernel paging request at virtual address ffffffffc0000000 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -510,6 +510,10 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, if (sme_active()) pr_warn_once("SME is active and system is using DMA bounce buffers\n"); + dev_warn(hwdev, "swiotlb_tbl_map_single: trying to map %zd bytes\n", size); + size = (size_t)524288; + dev_warn(hwdev, "swiotlb_tbl_map_single: test: size modified to %zd bytes\n", size);