Date: Fri, 21 Feb 2014 15:05:30 +0200 From: John Hay <jhay@meraka.org.za> To: freebsd-arm@freebsd.org Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140221130530.GA202@zibbi.meraka.csir.co.za> In-Reply-To: <20140219172938.GH34851@funkthat.com> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@meraka.csir.co.za / jhay@meraka.org.za
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140221130530.GA202>