From owner-freebsd-arm@FreeBSD.ORG Sat Dec 7 00:10:35 2013 Return-Path: Delivered-To: arm@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 E3DF5732 for ; Sat, 7 Dec 2013 00:10:34 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB53B1008 for ; Sat, 7 Dec 2013 00:10:34 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so2600306iec.30 for ; Fri, 06 Dec 2013 16:10:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=EQj/pCwCgWy+9eXqmGHZ0kZX58MbZK/nGnZpclQ/1K4=; b=cCqdWOyjkqvQ3SFZtJs5Ub+Ixis7Q+W7o/6ug6foMUaRsqVesNcXFRffFlhSkna3QR QfyxIJB6Hwtir3q/KBljp2Wi0s4boU26gCIGUT/onBV4BuEbWdxZaM8T1oJL2rPbxCge UDKvipIfI3mpWAq8lRCZVjA40O9qVOJHF+ooSIYrkhdBdUjugBIJn3HeeoRNlbZl2mNN GEyM3jdyHP2NakA/RayjrfL5VSU1v555d5E/Ke3SzUaoKR+GWMRFDqzRA2LGdYPs8cHu J6IEeiHtv4paK8klazRo1VGDAvk1SCE4XiyUqj0vJnaf1aNrYTHHv432s65VcfZdl8ce APVg== X-Gm-Message-State: ALoCoQnop6mBBIS+w7elaW9m6+KEmne9AxtGdQD93DevGjqJDF4RZ2BEUxKdaYkKYitMWpoGnVYI X-Received: by 10.43.170.130 with SMTP id nq2mr242850icc.69.1386375028364; Fri, 06 Dec 2013 16:10:28 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPSA id v9sm428340igh.7.2013.12.06.16.10.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 16:10:27 -0800 (PST) Sender: Warner Losh Subject: Re: Another issue with MFC Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1386373317.58852.123.camel@revolution.hippie.lan> Date: Fri, 6 Dec 2013 17:10:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20BF3C41-C593-4DF8-AB03-D4CD1132901D@bsdimp.com> References: <423CAA53-FC07-4939-A6C8-4FC69CA0F33E@bsdimp.com> <1386373317.58852.123.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) 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: Sat, 07 Dec 2013 00:10:35 -0000 On Dec 6, 2013, at 4:41 PM, Ian Lepore wrote: > On Thu, 2013-12-05 at 22:22 -0700, Warner Losh wrote: >> Hey Scott, >>=20 >> 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... >>=20 >> = ------------------------------------------------------------------------ >> r251874 | scottl | 2013-06-17 18:36:53 -0600 (Mon, 17 Jun 2013) | 34 = lines >>=20 >> 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. >>=20 >> MFC r246713: >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Submitted by: kib, jeffr >> Approved by: kib >> Obtained from: Netflix >>=20 >> = ------------------------------------------------------------------------ >>=20 >> Any ideas? >>=20 >> Warner >=20 > I wonder if an MFC of r246881 would help? If I update to r251874 and then apply this diff, then I don't see this = issue. Thanks! I'll see if my latest fix + this MFC makes it work... Warner=