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