From owner-freebsd-arm@FreeBSD.ORG Fri Dec 6 23:42:07 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F371689A for ; Fri, 6 Dec 2013 23:42:06 +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 C69891E35 for ; Fri, 6 Dec 2013 23:42:06 +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 1Vp520-0005gV-0R; Fri, 06 Dec 2013 23:42:00 +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 rB6NfvO2024592; Fri, 6 Dec 2013 16:41:57 -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: U2FsdGVkX19ShLWEAog59Gbpk6IfTVsy Subject: Re: Another issue with MFC From: Ian Lepore To: Warner Losh In-Reply-To: <423CAA53-FC07-4939-A6C8-4FC69CA0F33E@bsdimp.com> References: <423CAA53-FC07-4939-A6C8-4FC69CA0F33E@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Dec 2013 16:41:57 -0700 Message-ID: <1386373317.58852.123.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" , Scott Long X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:42:07 -0000 On Thu, 2013-12-05 at 22:22 -0700, Warner Losh wrote: > Hey Scott, > > I've found another problem. After the MFC of r251874, Atmel ARM no longer can boot off NFS because the network breaks across this commit... > > ------------------------------------------------------------------------ > r251874 | scottl | 2013-06-17 18:36:53 -0600 (Mon, 17 Jun 2013) | 34 lines > > Big MFC of the physbio changes necessary for unmapped I/O. These changes > have been in production at Netflix for several months with significant > success. > > MFC r246713: > > Reform the busdma API so that new types may be added without modifying > every architecture's busdma_machdep.c. It is done by unifying the > bus_dmamap_load_buffer() routines so that they may be called from MI > code. The MD busdma is then given a chance to do any final processing > in the complete() callback. > > MFC r249538: > Some compilers issue a warning when wider integer is casted to narrow > pointer. Supposedly shut down the warning by casting through > uintptr_t. > > MFC r251479: > Simplify the checking of flags for cam_periph_mapmem(). This gets rid of > a lot of code redundancy and grossness at very minor expense. > > MFC r251837: > MFC r251842: > Add infrastructure for doing compatibility shims, as has been sorely > needed for the last 10 years. Far too much of the internal API is > exposed, and every small adjustment causes applications to stop working. > To kick this off, bump the API version to 0x17 as should have been done > with r246713, but add shims to compensate. Thanks to the shims, there > should be no visible change in application behavior. > > Submitted by: kib, jeffr > Approved by: kib > Obtained from: Netflix > > ------------------------------------------------------------------------ > > Any ideas? > > Warner I wonder if an MFC of r246881 would help? -- Ian