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