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
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
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
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
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
> architecture. That said, I do
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 th
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 s
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 04.02.17 20:54, Jason Harme
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
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
> pointer wired into the loca
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
globall
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 mailto:l...@pix.net>> wrote:
Havi
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 state it was this
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 0xf
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?
T
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
> replace pcpu_find(
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
head/sys/kern/kern_rm
15 matches
Mail list logo