Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753054AbdIEUcy (ORCPT ); Tue, 5 Sep 2017 16:32:54 -0400 Received: from muru.com ([72.249.23.125]:39614 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752176AbdIEUct (ORCPT ); Tue, 5 Sep 2017 16:32:49 -0400 Date: Tue, 5 Sep 2017 13:32:44 -0700 From: Tony Lindgren To: Vlastimil Babka Cc: Pavel Machek , pali.rohar@gmail.com, sre@kernel.org, kernel list , linux-arm-kernel , linux-omap@vger.kernel.org, khilman@kernel.org, aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com, patrikbachan@gmail.com, serge@hallyn.com, abcloriens@gmail.com, Joonsoo Kim , "Aneesh Kumar K.V" , Andrew Morton , Stephen Rothwell , Russell King Subject: Re: n900 in next-20170901 Message-ID: <20170905203240.GF5024@atomide.com> References: <20170903203737.GA12475@amd> <20170905201314.GE5024@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1222 Lines: 35 * Vlastimil Babka [170905 13:29]: > On 09/05/2017 10:13 PM, Tony Lindgren wrote: > > * Pavel Machek [170903 13:38]: > >> Hi! > >> > >> It compiles ok, but it hangs on boot; black screen, so sometime before > >> display is initialized. > > > > Thanks for reporting it. Based on git bisect, the regression causing > > commit is 9caf25f996e8 ("mm/cma: manage the memory of the CMA area > > by using the ZONE_MOVABLE"). With this path applied, booting hangs > > with an error in omap3_save_secure_ram_context() after a call to > > _omap_save_secure_sram() that calls the related assembly code > > save_secure_ram_context. > > > > However, looks like there is also some other commit causing issue. > > > > Just reverting 9caf25f996e8 on Linux next causes the oops below. > > > > Anybody got ideas why this now happens? > > I know that there are other two patches from the same series depending > on the one you reverted: > > mm/cma: remove ALLOC_CMA > ARM: CMA: avoid double mapping to the CMA area if CONFIG_HIGHMEM = y > > I'm guessing you need to revert all to have something consistent to test. Thanks, yes reverting all three in next makes things boot for me again. Regards, Tony