Another issue with MFC

Ian Lepore ian at FreeBSD.org
Fri Dec 6 23:42:07 UTC 2013


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




More information about the freebsd-arm mailing list