svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include

[Andreas Tobler]

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 at gmail.com <mailto:jason.harmening at 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