From owner-freebsd-arm@FreeBSD.ORG Mon Nov 24 16:13:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02C139E for ; Mon, 24 Nov 2014 16:13:51 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2BE5A3D for ; Mon, 24 Nov 2014 16:13:50 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XswGr-000IMP-4s; Mon, 24 Nov 2014 16:13:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAOGDlRG010855; Mon, 24 Nov 2014 09:13:47 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+f0cbjfK8Bi5zf/nULdG/H X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Test Run with Alternative pmap Implementation From: Ian Lepore To: Ulrich Grey In-Reply-To: <20141124164006.ce3e101e04828df66bacada5@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141124164006.ce3e101e04828df66bacada5@ulrich-grey.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 2014 09:13:46 -0700 Message-ID: <1416845626.1147.391.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:13:51 -0000 On Mon, 2014-11-24 at 16:40 +0100, Ulrich Grey wrote: > On Mon, 24 Nov 2014 07:53:34 -0700 > Ian Lepore wrote: > > Hello, > > I've also been testing those pmap changes this weekend. The only change > > I made was to add options ARM_NEW_PMAP and NKPT2PG=64 to the kernel > > config. In particular, I did not change VM_MEMATTR_UNCACHEABLE (so that > > in effect I'm also testing the recent busdma changes). > > Here is the reason, why I changed VM_MEMATTR_UNCACHEABLE > (from an email to Svatopluk Kraus): > > When I tried to log into the system with ssh, it lasts a minute or more > to get an input prompt. It is the kernel, that was compiled with: > > options NKPT2PG=64 > > I tried to reduce the number (32, 26, 23, 21). 20 is the default in > sys/arm/include/pmap-v6.h and crashes the system, # 21 works! If I > decrease the numbers, the delay is reduced but remains cumbersome. If I > use the kernel with old pmap, no delay is noticeable. > > If I use the TAB-key for autocompletition, there is a delay of some > seconds until the prompt appears. If I press the RIGHT-ARROW-key after > the TAB-key, sometimes it is faster. In the editor ee the cursor > disappears for seconds. I have never observed such a behavior before. > > This appears only with ssh. On the serial console there is no delay. > Is there any way to improve that? > > The answer from Svatopluk Kraus: > > I have only one idea for now what you can try. We changed memory attributes > for uncacheable DMA buffers. However, some not well designed drivers could > have unpredictable behaviour now. Get sys/arm/include/vm.h file and > change following line: > > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_NOCACHE > > to > > #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO > > My answer: > > I have changed sys/arm/include/vm.h > and rebuild the kernel. > > The normal behavior is back. Oh, of course! This is my fault and I forgot all about it, I'm sorry. There is a bug in the ffec driver that was being masked by the VM_MEMATTR_SO, I discovered it right away Saturday morning when I applied the pmap patches (I couldn't even boot with nfsroot), fixed it, then forgot to commit the fix. I'll go commit it right now (r274967), then you should be able to set the MEMATTR back to VM_MEMATTR_NOCACHE. We may find similar trouble in other device drivers, especially network drivers. -- Ian