Skip site navigation (1)Skip section navigation (2)
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>