Date: Sun, 5 Feb 2017 22:06:46 +0100 From: Andreas Tobler <andreast@FreeBSD.org> To: Jason Harmening <jason.harmening@gmail.com>, Svatopluk Kraus <onwahe@gmail.com> Cc: Kurt Lidl <lidl@pix.net>, Alexander Kabaev <kabaev@gmail.com>, "Jason A. Harmening" <jah@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Ed Maste <emaste@freebsd.org>, Justin Hibbits <jrh29@alumni.cwru.edu> Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include Message-ID: <cc3d97d3-80f8-43ad-d863-a4c78b56942d@FreeBSD.org> In-Reply-To: <CAM=8qanyz08tAHvo7q2Dxt=Q6jWKqD53iF82wtFtN86fMXctQA@mail.gmail.com> References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> <CAM=8qa=h3=sfro02hCQyzqkDnLO7TnQJ8ugCoa5=MfNE_OCgZg@mail.gmail.com> <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> <CAM=8qa=YB_kBsFRS%2Ba7kR%2BZTkyjmRnwY7r9vfZ48SyyZ2BZddg@mail.gmail.com> <6bf86e46-9714-c7e9-8d47-845761e2de24@FreeBSD.org> <CAM=8qa=dEfeV%2BBLr7g7-9YiSP9uGyxzkzP1NEEz4xZ6TDUJ2HA@mail.gmail.com> <8a2f7f7d-14c3-8e75-e060-fc41213ce389@FreeBSD.org> <CAM=8qa=2rpHi8Jdbv23KN70M1CVx=gGO54fvTk38uYP9iEqa2g@mail.gmail.com> <CAFHCsPXdRya9xVgoi-DfuzutYZ-LdpntFy9t7GbBY1KvQZxdpA@mail.gmail.com> <CAM=8qakqOjn0x%2BFwLGG8qrAbksQ_VR4547_vRV%2Bqso%2Bu=Cdf1A@mail.gmail.com> <CAM=8qanyz08tAHvo7q2Dxt=Q6jWKqD53iF82wtFtN86fMXctQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05.02.17 19:59, Jason Harmening wrote: > Actually attaching the patch this time (**** gmail client) > > On Sun, Feb 5, 2017 at 10:58 AM, Jason Harmening > <jason.harmening@gmail.com <mailto:jason.harmening@gmail.com>> wrote: > > Hmm, it's a good idea to consider the possibility of a barrier > issue. It wouldn't be the first time we've had such a problem on a > weakly-ordered architecture. That said, I don't see a problem in > this case. smp_rendezvous_cpus() takes a spinlock and then issues > atomic_store_rel_int() to ensure the rendezvous params are visible > to other cpus. The latter corresponds to lwsync on powerpc, which > AFAIK should be sufficient to ensure visibility of prior stores. > > For now I'm going with the simpler explanation that I made a bad > assumption in the powerpc get_pcpu() and there is some context in > which the read of sprg0 doesn't return a consistent pointer value. > Unfortunately I don't see where that might be right now. > > On the mips side, Kurt/Alexander can you test the attached patch? > It contains a simple fix to ensure get_pcpu() returns the consistent > per-cpu pointer. Here the panic I received with the latest patch you sent. World & kernel are on 313286 + patch. https://people.freebsd.org/~andreast/pcpu/ It is the same panic, pic 2 is with a try to get a core .... The load issue was a gmake -j8 bootstrap of todays gcc trunk sources. The machine has 2 physical CPU's, two threads pre cpu :) I revert now and see if the situation becomes stable again or if there is something else. Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cc3d97d3-80f8-43ad-d863-a4c78b56942d>