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.harmen...@gmail.com <mailto:jason.harmen...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
