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

On 2/5/17 1:59 PM, Jason Harmening wrote: Actually attaching the patch this time ( gmail client) On Sun, Feb 5, 2017 at 10:58 AM, Jason Harmening > wrote: Hmm, it's a good idea to consider the possibility of a barrier

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

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 > wrote: Hmm, it's a good idea to consider the possibility of a barrier

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

Actually attaching the patch this time ( gmail client) On Sun, Feb 5, 2017 at 10:58 AM, Jason Harmening 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 >

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

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

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

Probably not related. But when I took short look to the patch to see what could go wrong, I walked into the following comment in _rm_wlock(): "Assumes rm->rm_writecpus update is visible on other CPUs before rm_cleanIPI is called." There is no explicit barrier to ensure it. However, there might be

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

Can you post an example of such panic? Only 2 MI pieces were changed, netisr and rmlock. I haven't seen problems on my own amd64/i386/arm testing of this, so a backtrace might help to narrow down the cause. On Sat, Feb 4, 2017 at 12:22 PM, Andreas Tobler wrote: > On

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

On 04.02.17 20:54, Jason Harmening wrote: I suspect this broke rmlocks for mips because the rmlock implementation takes the address of the per-CPU pc_rm_queue when building tracker lists. That address may be later accessed from another CPU and will then translate to the wrong physical region if

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

On Fri, 3 Feb 2017 21:29:33 -0800 Jason Harmening wrote: > Hi, > > I'm a bit confused as to how this change breaks MIPS. The new > function, get_pcpu() is intended to be used only to access the > per-cpu data pointer locally. It returns pcpup, which is the per-cpu >

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

I suspect this broke rmlocks for mips because the rmlock implementation takes the address of the per-CPU pc_rm_queue when building tracker lists. That address may be later accessed from another CPU and will then translate to the wrong physical region if the address was taken relative to the

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

On 04.02.17 07:27, Jason Harmening wrote: It's hard to argue with that:) I've backed it out until we can figure out what's going on. Sorry for the breakage. For the record, powerpc64 was also affected. Andreas On Fri, Feb 3, 2017 at 9:54 PM, Kurt Lidl >

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

It's hard to argue with that:) I've backed it out until we can figure out what's going on. Sorry for the breakage. On Fri, Feb 3, 2017 at 9:54 PM, Kurt Lidl wrote: > Having just spent a couple of hours bisecting what broke the kernel on > my mips64 machine, I can definitively

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

Having just spent a couple of hours bisecting what broke the kernel on my mips64 machine, I can definitively state it was this commit. With this commit in place, the kernel hangs early in the autoconfiguration: gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "kernel" at

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

Hi, I'm a bit confused as to how this change breaks MIPS. The new function, get_pcpu() is intended to be used only to access the per-cpu data pointer locally. It returns pcpup, which is the per-cpu pointer wired into the local TLB to translate to the local CPU's physical data region, correct?

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

On Wed, 1 Feb 2017 03:32:49 + (UTC) "Jason A. Harmening" wrote: > Author: jah > Date: Wed Feb 1 03:32:49 2017 > New Revision: 313037 > URL: https://svnweb.freebsd.org/changeset/base/313037 > > Log: > Implement get_pcpu() for the remaining architectures and use it to >

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

Author: jah Date: Wed Feb 1 03:32:49 2017 New Revision: 313037 URL: https://svnweb.freebsd.org/changeset/base/313037 Log: Implement get_pcpu() for the remaining architectures and use it to replace pcpu_find(curcpu) in MI code. Modified: head/sys/amd64/include/pcpu.h