status of AVILA and CAMBRIA code

[Ian Lepore]

On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote:
> On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote:
> > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200:
> > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody
> > > had success recently? From the lists I can see that other people have
> > > also asked in September 2013, but I cannot figure out if there was any
> > > successes at that stage. :-)
> ...
> > > 
> > > Somewhere along the line the ethernet npe0 device also broke, writing
> > > "npe0: npestart_locked: too many fragments 0". But I did not test the
> > > npe0 device with every build and only realised it this morning, so I
> > > do not know where it broke. :-)
> > 
> > Not sure about these issues...
> 
> Ok, I found the place. It is svn 246713 by kib:
> 
> ###########
> 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.
> 
> The cam changes unify the bus_dmamap_load* handling in cam drivers.
> 
> The arm and mips implementations are updated to track virtual
> addresses for sync().  Previously this was done in a type specific
> way.  Now it is done in a generic way by recording the list of
> virtuals in the map.
> 
> Submitted by:	jeff (sponsored by EMC/Isilon)
> Reviewed by:	kan (previous version), scottl,
> 	mjacob (isp(4), no objections for target mode changes)
> Discussed with:	     ian (arm changes)
> Tested by:	marius (sparc64), mips (jmallet), isci(4) on x86 (jharris),
> 	amd64 (Fabian Keil <freebsd-listen at fabiankeil.de>
> ###########
> 
> After that tx packets will cause this message:
> npe0: npestart_locked: too many fragments.
> 
> Then updating to 246881 by ian:
> 
> #############
> In _bus_dmamap_addseg(), the return value must be zero for error, or the size
> actually added to the segment (possibly smaller than the requested size if
> boundary crossings had to be avoided).
> #############
> 
> This makes it a bit better in that some packets seem to go through. It
> looks like 3 out of 4 will go out and the forth will cause the same
> message as above.
> 
> I have added a printf just above bus_dmamap_load_mbuf_sg() in
> npestart_locked() to show some of the mbuf values:
> 
> ############
> npe0: npestart_locked: m_len 42, data 0xc0d3dcd6, next 0
> [...]
> ############
> 
> Any ideas?
> 
> John

I can't see the path through the busdma code that leads to that result.
It looks like there are two ways the mapping can fail, maybe it would
help to know which path it's taking.  In arm/busdma_machdep.c the two
error paths out of the mapping loop are at lines 1066 and 1077, could
you try putting printfs at those locations so we know which case is
happening?  Maybe printing some of the values involved with taking those
exits would be helpful too.

Maybe also check for map->sync_count being non-zero on entry to
_bus_dmamap_load_buffer() and print something if it is.  The printfs you
did earlier make it look like there's never actually a second mbuf
chained off the first (which makes sense for such small packets), I
think that number should always be zero on entry because the outer loop
in kern/subr_bus_dma.c should only ever run once.

-- Ian