From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Zr8A8-0003Ia-Jt for barebox@lists.infradead.org; Tue, 27 Oct 2015 17:36:01 +0000 Received: by wikq8 with SMTP id q8so222536873wik.1 for ; Tue, 27 Oct 2015 10:35:34 -0700 (PDT) Date: Tue, 27 Oct 2015 18:35:27 +0100 From: Alexander Aring Message-ID: <20151027173526.GA9341@omega> References: <1445934602-25903-1-git-send-email-s.hauer@pengutronix.de> <20151027165459.GA4592@omega> <20151027172742.GA8942@omega> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151027172742.GA8942@omega> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: memtest updates To: Sascha Hauer Cc: Barebox List On Tue, Oct 27, 2015 at 06:27:42PM +0100, Alexander Aring wrote: > On Tue, Oct 27, 2015 at 05:54:59PM +0100, Alexander Aring wrote: > > On Tue, Oct 27, 2015 at 09:29:53AM +0100, Sascha Hauer wrote: > > > This series has some updates for the memory test. The output and the > > > code are made more compact and some additional options are added. Also > > > the remap_range function is reworked. > > > > > > ... > > > > What means 0xdeadbeef here? > > okay, I it's guess the pattern argument which doesn't exist anymore. > > I run memtest now with: > > memtest -t -u > > on the RPi and it seems the first progressbar range of "0/3" - "1/3" runs > faster than the last range of "1/3" - "3/3". > > This sounds like that remap_range does not full manipulate the range > of page tables (the range at the start address). Okay we can't full use > the range, because we need to be PAGE_ALIGN, but the whole first range of > "0/3" - "1/3" sounds not correct for me (it's bigger than PAGE_ALIGN). > > Maybe everything is correct and the first address room is always a > little bit faster than the others, but I don't think that. > > I haven't tried to debug this issue. Can somebody confirm that on an > other arm board? > okay, false alarm. It's confusing me, we do not always the same operation in each progressbar step. We doing in the first part filling some pattern, in second/third part we doing filling pattern and compare. This is why it takes longer. It just looks like some area is still cached and the other uncached. - Alex _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox