Date: Mon, 3 Mar 2014 08:29:44 +0200 From: John Hay <jhay@meraka.org.za> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140303062944.GC85204@zibbi.meraka.csir.co.za> In-Reply-To: <1393820901.1149.276.camel@revolution.hippie.lan> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> <1393001249.1145.98.camel@revolution.hippie.lan> <20140224132614.GA31984@zibbi.meraka.csir.co.za> <20140301104431.GA82389@zibbi.meraka.csir.co.za> <1393818757.1149.267.camel@revolution.hippie.lan> <20140303040631.GA85204@zibbi.meraka.csir.co.za> <1393820901.1149.276.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 02, 2014 at 09:28:21PM -0700, Ian Lepore wrote: > On Mon, 2014-03-03 at 06:06 +0200, John Hay wrote: > > On Sun, Mar 02, 2014 at 08:52:37PM -0700, Ian Lepore wrote: > > > On Sat, 2014-03-01 at 12:44 +0200, John Hay wrote: > > > > On Mon, Feb 24, 2014 at 03:26:14PM +0200, John Hay wrote: > > > > > Hi Ian, > > > > > > > > > > On Fri, Feb 21, 2014 at 09:47:29AM -0700, Ian Lepore wrote: > > > > > > 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. :-) > > > > > > > > It looks like adding a few bus_dmamap_unload()s in if_npe.c fixed it. Here is > > > > my patch that seems to fix it. Does it look ok? Can I commit it? > > > > > > > > Index: xscale/ixp425/if_npe.c > > > > =================================================================== > > > > --- xscale/ixp425/if_npe.c (revision 246713) > > > > +++ xscale/ixp425/if_npe.c (working copy) > > > > @@ -1037,6 +1037,8 @@ > > > > > > > > sc = npes[NPE_QM_Q_NPE(entry)]; > > > > npe = P2V(NPE_QM_Q_ADDR(entry), &sc->txdma); > > > > + bus_dmamap_sync(sc->txdma.mtag, npe->ix_map, BUS_DMASYNC_POSTWRITE); > > > > + bus_dmamap_unload(sc->txdma.mtag, npe->ix_map); > > > > m_freem(npe->ix_m); > > > > npe->ix_m = NULL; > > > > > > > > @@ -1112,6 +1114,12 @@ > > > > > > > > DPRINTF(sc, "%s: entry 0x%x neaddr 0x%x ne_len 0x%x\n", > > > > __func__, entry, npe->ix_neaddr, npe->ix_hw->ix_ne[0].len); > > > > + > > > > + /* Flush mbuf memory for rx'd data */ > > > > + bus_dmamap_sync(dma->mtag, npe->ix_map, > > > > + BUS_DMASYNC_POSTREAD); > > > > + bus_dmamap_unload(dma->mtag, npe->ix_map); > > > > + > > > > /* > > > > * Allocate a new mbuf to replenish the rx buffer. > > > > * If doing so fails we drop the rx'd frame so we > > > > @@ -1126,10 +1134,6 @@ > > > > struct npehwbuf *hw = npe->ix_hw; > > > > struct ifnet *ifp = sc->sc_ifp; > > > > > > > > - /* Flush mbuf memory for rx'd data */ > > > > - bus_dmamap_sync(dma->mtag, npe->ix_map, > > > > - BUS_DMASYNC_POSTREAD); > > > > - > > > > /* XXX flush hw buffer; works now 'cuz coherent */ > > > > /* set m_len etc. per rx frame size */ > > > > mrx->m_len = be32toh(hw->ix_ne[0].len) & 0xffff; > > > > > > > > John > > > > > > I think this is more correct, but one more thing is needed... it looks > > > like design here was to load a map then not unload it until the next > > > time you're about to load it. I think that's a bad idea and your > > > changes are the better way, but there are still a few unload calls > > > scattered around that now need to be deleted because they would be > > > unloading a map that was already unloaded when the IO completed. > > > > Thanks, I'll look into the other unloads. I get the feeling that the > > design was actually to only unload if the interface is stopped which > > worked fine until map->sync_count was introduced in arm/busdma_machdep.c? > > > > Regards > > > > John > > In both the places where bus_dmamap_load_mbuf_sg() is called, an unload > is done right before the load. It's almost like an attempt to hoard > resources lest something else grab them while the driver is idle. :) Ahh, we have been looking at different versions of the file. I have been looking at an older version, because I cannot get any console output with the src tree after about August last year. Neither with -current or with 10-stable. I see that cogent made a commit to try and fix this issue on Oct 22, svn 256943. I'll have a look at that. Maybe one day I'll be able to run the Avila/Cambrias on a recentish code base. :-) 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?20140303062944.GC85204>