From owner-svn-src-head@FreeBSD.ORG Fri Jan 3 16:49:23 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1442449C; Fri, 3 Jan 2014 16:49:23 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D92601DF4; Fri, 3 Jan 2014 16:49:22 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz7vv-000EEW-Pt; Fri, 03 Jan 2014 16:49:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s03GnC0v024082; Fri, 3 Jan 2014 09:49:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 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+dLp8pL+a/+RbvGe/Xl5S/ Subject: Re: svn commit: r260165 - head/sys/dev/ahci From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140101203212.GF59496@kib.kiev.ua> References: <201401012026.s01KQ8KU017949@svn.freebsd.org> <20140101203212.GF59496@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 09:49:12 -0700 Message-ID: <1388767752.1158.264.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Zbigniew Bodek , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 16:49:23 -0000 On Wed, 2014-01-01 at 22:32 +0200, Konstantin Belousov wrote: > On Wed, Jan 01, 2014 at 08:26:08PM +0000, Zbigniew Bodek wrote: > > Author: zbb > > Date: Wed Jan 1 20:26:08 2014 > > New Revision: 260165 > > URL: http://svnweb.freebsd.org/changeset/base/260165 > > > > Log: > > Use only mapped BIOs on ARM > > > > Using unmapped BIOs causes failure inside bus_dmamap_sync, since > > this function requires valid MVA address, which is not present > > if mapping is not set up. > > > > Submitted by: Wojciech Macek > > Obtained from: Semihalf > > > > Modified: > > head/sys/dev/ahci/ahci.c > > > > Modified: head/sys/dev/ahci/ahci.c > > ============================================================================== > > --- head/sys/dev/ahci/ahci.c Wed Jan 1 20:22:29 2014 (r260164) > > +++ head/sys/dev/ahci/ahci.c Wed Jan 1 20:26:08 2014 (r260165) > > @@ -3066,7 +3066,15 @@ ahciaction(struct cam_sim *sim, union cc > > if (ch->caps & AHCI_CAP_SPM) > > cpi->hba_inquiry |= PI_SATAPM; > > cpi->target_sprt = 0; > > +#ifdef __arm__ > > + /* > > + * Do not use unmapped buffers on ARM. Doing so will cause > > + * failure inside bus_dmamap_sync due to lack of VA. > > + */ > > + cpi->hba_misc = PIM_SEQSCAN; > > +#else > > cpi->hba_misc = PIM_SEQSCAN | PIM_UNMAPPED; > > +#endif > > cpi->hba_eng_cnt = 0; > > if (ch->caps & AHCI_CAP_SPM) > > cpi->max_target = 15; > > I think this is wrong. If bus_dmamap_sync(9) is not functional on arm, > then unmapped io should be disabled on arm unconditionally, using > unmapped_buf_allowed. Why ahci(4) is special in this regard, leaving > other controllers broken for arm ? I think this entire concept is wrong, and the fix should be in armv6 busdma or pmap code. An unmapped page is, by definition, not cached. The only way data becomes cached is because flags in a mapping indicated the memory is cacheable. If we have data from unmapped pages in the cache, that's a bug in the armv6 pmap implementation, I think. -- Ian