status of AVILA and CAMBRIA code
John Hay
jhay at meraka.org.za
Fri Feb 21 13:05:34 UTC 2014
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
npe0: npestart_locked: m_len 42, data 0xc0d45dd6, next 0
npe0: npestart_locked: m_len 42, data 0xc11872d6, next 0
npe0: npestart_locked: m_len 342, data 0xc11c2800, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc0d434d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d449d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d428d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d402d6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc0d3e3d6, next 0
npe0: npestart_locked: m_len 42, data 0xc118d2d6, next 0
npe0: npestart_locked: m_len 342, data 0xc1192800, next 0
npe0: npestart_locked: m_len 342, data 0xc11b4800, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc118b8d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d412d6, next 0
npe0: npestart_locked: m_len 42, data 0xc118e9d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d422d6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc0d424d6, next 0
npe0: npestart_locked: m_len 42, data 0xc118d0d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d415d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d40cd6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc118acd6, next 0
npe0: npestart_locked: m_len 42, data 0xc118e2d6, next 0
npe0: npestart_locked: m_len 42, data 0xc11891d6, next 0
npe0: npestart_locked: m_len 42, data 0xc1187ed6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc0d3d8d6, next 0
npe0: npestart_locked: m_len 42, data 0xc11897d6, next 0
npe0: npestart_locked: m_len 42, data 0xc118e8d6, next 0
npe0: npestart_locked: m_len 42, data 0xc118c0d6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc0d3e2d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d40ed6, next 0
npe0: npestart_locked: m_len 42, data 0xc1188ad6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d3f8d6, next 0
npe0: npestart_locked: too many fragments 0
npe0: npestart_locked: m_len 42, data 0xc118e5d6, next 0
npe0: npestart_locked: m_len 42, data 0xc0d3d6d6, next 0
############
Any ideas?
John
--
John Hay -- jhay at meraka.csir.co.za / jhay at meraka.org.za
More information about the freebsd-arm
mailing list