Date: Fri, 6 Dec 2013 17:10:25 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" <arm@FreeBSD.org>, Scott Long <scottl@samsco.org> Subject: Re: Another issue with MFC Message-ID: <20BF3C41-C593-4DF8-AB03-D4CD1132901D@bsdimp.com> In-Reply-To: <1386373317.58852.123.camel@revolution.hippie.lan> References: <423CAA53-FC07-4939-A6C8-4FC69CA0F33E@bsdimp.com> <1386373317.58852.123.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20BF3C41-C593-4DF8-AB03-D4CD1132901D>