Date: Sat, 06 Sep 2014 17:28:48 -0500 From: Alan Cox <alc@rice.edu> To: Adrian Chadd <adrian@freebsd.org>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org>, Alan Cox <alc@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: bug 193400: sfbuf changes on mips32 may have exposed some vm/pmap issues on mips32? Message-ID: <540B8AA0.40005@rice.edu> In-Reply-To: <CAJ-Vmo=Y77btZq0iRxROACNj0WDzGrz0Dvx7FExhPOZVyRjKsg@mail.gmail.com> References: <CAJ-Vmo=Y77btZq0iRxROACNj0WDzGrz0Dvx7FExhPOZVyRjKsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/06/2014 17:24, Adrian Chadd wrote: > Hi! > > This bug: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193400 > > is what I reported to alc a couple weeks ago as breaking on my 128mb > RAM mipsbe board. > > It turns out that the difference between the MIPS32 sfbuf code and the > new stuff gleb added was the refcounting side of things. With the MIPS > code, there was no refcounting at all - each sfbuf allocation would > allocate a new sfbuf. Now, I don't know how correct that is (my > reading of the code is "not correct!") but it wasn't panicing things. > > So I think maybe gleb's patch to sfbuf exposed a MIPS32 pmap/VM bug? > > Alan - how would we go about figuring out what could be the issue here? I just sent you an email a few minutes ago describing how to restore the old behavior. > I'd really appreciate some help here as I'd like to keep the MIPS32 > stuff in good shape. :) > > Thanks! > > > -a >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540B8AA0.40005>