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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=ham 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 AD6F9C433DB for ; Tue, 12 Jan 2021 10:53:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 37E6D2250E for ; Tue, 12 Jan 2021 10:53:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37E6D2250E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A2F398D0091; Tue, 12 Jan 2021 05:53:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B7B98D0090; Tue, 12 Jan 2021 05:53:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8814E8D0091; Tue, 12 Jan 2021 05:53:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 6F5758D0090 for ; Tue, 12 Jan 2021 05:53:50 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 31AAB1EF1 for ; Tue, 12 Jan 2021 10:53:50 +0000 (UTC) X-FDA: 77696812620.07.prose83_5e0b68827514 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 163DB1803F9A4 for ; Tue, 12 Jan 2021 10:53:50 +0000 (UTC) X-HE-Tag: prose83_5e0b68827514 X-Filterd-Recvd-Size: 4277 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 10:53:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: gtucker) with ESMTPSA id DC3B61F413F8 Subject: Re: kernelci/staging-next bisection: sleep.login on rk3288-rock2-square #2286-staging To: Mike Rapoport , Andrea Arcangeli Cc: Andrew Morton , Stephen Rothwell , kernelci-results-staging@groups.io, "kernelci-results@groups.io" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Rapoport , Baoquan He References: <5fd3e5d9.1c69fb81.f9e69.5028@mx.google.com> <127999c4-7d56-0c36-7f88-8e1a5c934cae@collabora.com> <20201213082314.GA198221@linux.ibm.com> <0633d44a-3796-8a1b-e5dc-99fc62aa4dc7@collabora.com> <20210103134753.GC832698@linux.ibm.com> <20210105091330.GD832698@linux.ibm.com> From: Guillaume Tucker Message-ID: <28e59120-f8b9-7256-325a-1e4ca90887b5@collabora.com> Date: Tue, 12 Jan 2021 10:53:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210105091330.GD832698@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 05/01/2021 09:13, Mike Rapoport wrote: > On Sun, Jan 03, 2021 at 03:09:14PM -0500, Andrea Arcangeli wrote: >> Hello Mike, >> >> On Sun, Jan 03, 2021 at 03:47:53PM +0200, Mike Rapoport wrote: >>> Thanks for the logs, it seems that implicitly adding reserved regions to >>> memblock.memory wasn't that bright idea :) >> >> Would it be possible to somehow clean up the hack then? >> >> The only difference between the clean solution and the hack is that >> the hack intended to achieved the exact same, but without adding the >> reserved regions to memblock.memory. > > I didn't consider adding reserved regions to memblock.memory as a clean > solution, this was still a hack, but I didn't think that things are that > fragile. > > I still think we cannot rely on memblock.reserved to detect > memory/zone/node sizes and the boot failure reported here confirms this. > >> The comment on that problematic area says the reserved area cannot be >> used for DMA because of some unexplained hw issue, and that doing so >> prevents booting, but since the area got reserved, even with the clean >> solution, it shouldn't have never been used for DMA? >> >> So I can only imagine that the physical memory region is way more >> problematic than just for DMA. It sounds like that anything that >> touches it, including the CPU, will hang the system, not just DMA. It >> sounds somewhat similar to the other e820 direct mapping issue on x86? > > My understanding is that the boot failed because when I implicitly added > the reserved region to memblock.memory the memory size seen by > free_area_init() jumped from 2G to 4G because the reserved area was close > to 4G. The very first allocation would get a chunk from slightly below of > 4G and as there is no real memory there, the kernel would crash. > >> If you want to test the hack on the arm board to check if it boots you >> can use the below commit: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/commit/?id=c3ea2633015104ce0df33dcddbc36f57de1392bc > > My take is your solution would boot with this memory configuration, but I > still don't think that using memblock.reserved for zone/node sizing is > correct. The rk3288 platform has now been failing to boot for nearly a month on linux-next: https://kernelci.org/test/case/id/5ffbed0a31ad81239bc94cdb/ Until a fix or a new version of this patch is made, would it be possible to drop it or revert it so the platform become usable again? Or if you want, I can make a cleaned-up version of my hack to ignore the problematic region if you still need your patch to be on linux-next, but that would probably be less than ideal. Thanks, Guillaume