Re: Linux process causes kernel panic
On 8/6/18 11:41 PM, Konstantin Belousov wrote: >>> linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401) >>> -- here it stops -- >> Can you fix your mail client ? Unfortunately, it did all that dumb wraps at send time not at edit. Sorry. >>> ddb also shows that process is looping somewhere inside linux_sys_futex() >> There are two bugs. One is that ifuncs handling for relocations against >> local symbols in elf obj modules was missed. Patch below fixed it for me. >> >> Second bug is that futexes seems to not handle accesses to the CoW >> mappings which are not yet copied. I think that the second bug is >> irrelevant for your case, since it worked before. >> >> Try this patch in addition to the linux/ patches I sent before. It fixed skype for me too! Thank you! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linux process causes kernel panic
On Mon, Aug 06, 2018 at 11:37:38PM +0300, Konstantin Belousov wrote:
> On Mon, Aug 06, 2018 at 06:24:43PM +0300, Vladimir Kondratyev wrote:
> > I've got similar panic right after skype start
> >
> > Disabling of SMAP via loader tunable workarounded the panic for me.
> >
> > Applying of the patch make skype eating 100%CPU in unkillable state.
> >
> > tail of ktrace dump
> >
> > 1238 skype CALL linux_gettid
> > 1238 skype RET linux_gettid 101123/0x18b03
> > 1238 skype CALL
> > linux_sys_futex(0x3301edc,0x84,0x1,0x7fff,0x3301ec0,0x2)
> > 1238 skype RET linux_sys_futex 0
> > 1238 skype CALL linux_sys_futex(0x33b0fac,0x80,0x1,0,0x33b0f90,0x1)
> > 1238 skype CALL linux_sys_futex(0x3301edc,0x80,0x1,0,0x3301ec0,0x1)
> > 1238 skype RET linux_sys_futex -1 errno -11 Resource temporarily
> > unavailable
> > 1238 skype CALL
> > linux_sys_futex(0x3301ec0,0x81,0x1,0x3301ec0,0x33b02c8,0xc168)
> > 1238 skype RET linux_sys_futex 0
> > 1238 skype CALL
> > linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401)
> > -- here it stops --
> Can you fix your mail client ?
>
> > ddb also shows that process is looping somewhere inside linux_sys_futex()
>
> There are two bugs. One is that ifuncs handling for relocations against
> local symbols in elf obj modules was missed. Patch below fixed it for me.
>
> Second bug is that futexes seems to not handle accesses to the CoW
> mappings which are not yet copied. I think that the second bug is
> irrelevant for your case, since it worked before.
>
> Try this patch in addition to the linux/ patches I sent before.
Wrong patch, I forgot to commit part of the changes.
diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
index 43f85bd17c9..94d29769142 100644
--- a/sys/kern/link_elf_obj.c
+++ b/sys/kern/link_elf_obj.c
@@ -142,7 +142,7 @@ static int link_elf_each_function_name(linker_file_t,
static int link_elf_each_function_nameval(linker_file_t,
linker_function_nameval_callback_t,
void *);
-static int link_elf_reloc_local(linker_file_t);
+static int link_elf_reloc_local(linker_file_t, bool);
static longlink_elf_symtab_get(linker_file_t, const Elf_Sym **);
static longlink_elf_strtab_get(linker_file_t, caddr_t *);
@@ -441,10 +441,9 @@ link_elf_link_preload(linker_class_t cls, const char
*filename,
}
/* Local intra-module relocations */
- error = link_elf_reloc_local(lf);
+ error = link_elf_reloc_local(lf, false);
if (error != 0)
goto out;
-
*result = lf;
return (0);
@@ -479,13 +478,18 @@ link_elf_link_preload_finish(linker_file_t lf)
ef = (elf_file_t)lf;
error = relocate_file(ef);
if (error)
- return error;
+ return (error);
/* Notify MD code that a module is being loaded. */
error = elf_cpu_load_file(lf);
if (error)
return (error);
+ /* Now ifuncs. */
+ error = link_elf_reloc_local(lf, true);
+ if (error != 0)
+ return (error);
+
/* Invoke .ctors */
link_elf_invoke_ctors(lf->ctors_addr, lf->ctors_size);
return (0);
@@ -969,7 +973,7 @@ link_elf_load_file(linker_class_t cls, const char *filename,
}
/* Local intra-module relocations */
- error = link_elf_reloc_local(lf);
+ error = link_elf_reloc_local(lf, false);
if (error != 0)
goto out;
@@ -990,6 +994,11 @@ link_elf_load_file(linker_class_t cls, const char
*filename,
if (error)
goto out;
+ /* Now ifuncs. */
+ error = link_elf_reloc_local(lf, true);
+ if (error != 0)
+ goto out;
+
/* Invoke .ctors */
link_elf_invoke_ctors(lf->ctors_addr, lf->ctors_size);
@@ -1374,7 +1383,10 @@ elf_obj_lookup(linker_file_t lf, Elf_Size symidx, int
deps, Elf_Addr *res)
/* Quick answer if there is a definition included. */
if (sym->st_shndx != SHN_UNDEF) {
- *res = sym->st_value;
+ res1 = (Elf_Addr)sym->st_value;
+ if (ELF_ST_TYPE(sym->st_info) == STT_GNU_IFUNC)
+ res1 = ((Elf_Addr (*)(void))res1)();
+ *res = res1;
return (0);
}
@@ -1470,7 +1482,7 @@ link_elf_fix_link_set(elf_file_t ef)
}
static int
-link_elf_reloc_local(linker_file_t lf)
+link_elf_reloc_local(linker_file_t lf, bool ifuncs)
{
elf_file_t ef = (elf_file_t)lf;
const Elf_Rel *rellim;
@@ -1505,8 +1517,13 @@ link_elf_reloc_local(linker_file_t lf)
/* Only do local relocs */
if (ELF_ST_BIND(sym->st_info) != STB_LOCAL)
continue;
- elf_reloc_local(lf, base, rel, ELF_RELOC_REL,
- elf_obj_lookup);
+
Re: Linux process causes kernel panic
On Mon, Aug 06, 2018 at 06:24:43PM +0300, Vladimir Kondratyev wrote:
> I've got similar panic right after skype start
>
> Disabling of SMAP via loader tunable workarounded the panic for me.
>
> Applying of the patch make skype eating 100%CPU in unkillable state.
>
> tail of ktrace dump
>
> 1238 skype CALL linux_gettid
> 1238 skype RET linux_gettid 101123/0x18b03
> 1238 skype CALL
> linux_sys_futex(0x3301edc,0x84,0x1,0x7fff,0x3301ec0,0x2)
> 1238 skype RET linux_sys_futex 0
> 1238 skype CALL linux_sys_futex(0x33b0fac,0x80,0x1,0,0x33b0f90,0x1)
> 1238 skype CALL linux_sys_futex(0x3301edc,0x80,0x1,0,0x3301ec0,0x1)
> 1238 skype RET linux_sys_futex -1 errno -11 Resource temporarily
> unavailable
> 1238 skype CALL
> linux_sys_futex(0x3301ec0,0x81,0x1,0x3301ec0,0x33b02c8,0xc168)
> 1238 skype RET linux_sys_futex 0
> 1238 skype CALL
> linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401)
> -- here it stops --
Can you fix your mail client ?
> ddb also shows that process is looping somewhere inside linux_sys_futex()
There are two bugs. One is that ifuncs handling for relocations against
local symbols in elf obj modules was missed. Patch below fixed it for me.
Second bug is that futexes seems to not handle accesses to the CoW
mappings which are not yet copied. I think that the second bug is
irrelevant for your case, since it worked before.
Try this patch in addition to the linux/ patches I sent before.
diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
index 43f85bd17c9..872cb79f38b 100644
--- a/sys/kern/link_elf_obj.c
+++ b/sys/kern/link_elf_obj.c
@@ -142,7 +142,7 @@ static int link_elf_each_function_name(linker_file_t,
static int link_elf_each_function_nameval(linker_file_t,
linker_function_nameval_callback_t,
void *);
-static int link_elf_reloc_local(linker_file_t);
+static int link_elf_reloc_local(linker_file_t, bool);
static longlink_elf_symtab_get(linker_file_t, const Elf_Sym **);
static longlink_elf_strtab_get(linker_file_t, caddr_t *);
@@ -441,7 +441,10 @@ link_elf_link_preload(linker_class_t cls, const char
*filename,
}
/* Local intra-module relocations */
- error = link_elf_reloc_local(lf);
+ error = link_elf_reloc_local(lf, false);
+ if (error != 0)
+ goto out;
+ error = link_elf_reloc_local(lf, true);
if (error != 0)
goto out;
@@ -969,7 +972,7 @@ link_elf_load_file(linker_class_t cls, const char *filename,
}
/* Local intra-module relocations */
- error = link_elf_reloc_local(lf);
+ error = link_elf_reloc_local(lf, false);
if (error != 0)
goto out;
@@ -985,6 +988,11 @@ link_elf_load_file(linker_class_t cls, const char
*filename,
if (error)
goto out;
+ /* Now ifuncs. */
+ error = link_elf_reloc_local(lf, true);
+ if (error != 0)
+ goto out;
+
/* Notify MD code that a module is being loaded. */
error = elf_cpu_load_file(lf);
if (error)
@@ -1374,7 +1382,10 @@ elf_obj_lookup(linker_file_t lf, Elf_Size symidx, int
deps, Elf_Addr *res)
/* Quick answer if there is a definition included. */
if (sym->st_shndx != SHN_UNDEF) {
- *res = sym->st_value;
+ res1 = (Elf_Addr)sym->st_value;
+ if (ELF_ST_TYPE(sym->st_info) == STT_GNU_IFUNC)
+ res1 = ((Elf_Addr (*)(void))res1)();
+ *res = res1;
return (0);
}
@@ -1470,7 +1481,7 @@ link_elf_fix_link_set(elf_file_t ef)
}
static int
-link_elf_reloc_local(linker_file_t lf)
+link_elf_reloc_local(linker_file_t lf, bool ifuncs)
{
elf_file_t ef = (elf_file_t)lf;
const Elf_Rel *rellim;
@@ -1505,8 +1516,13 @@ link_elf_reloc_local(linker_file_t lf)
/* Only do local relocs */
if (ELF_ST_BIND(sym->st_info) != STB_LOCAL)
continue;
- elf_reloc_local(lf, base, rel, ELF_RELOC_REL,
- elf_obj_lookup);
+ if ((ELF_ST_TYPE(sym->st_info) == STT_GNU_IFUNC) ==
+ ifuncs)
+ elf_reloc_local(lf, base, rel, ELF_RELOC_REL,
+ elf_obj_lookup);
+ else if (ifuncs)
+ elf_reloc_ifunc(lf, base, rel, ELF_RELOC_REL,
+ elf_obj_lookup);
}
}
@@ -1531,8 +1547,13 @@ link_elf_reloc_local(linker_file_t lf)
/* Only do local relocs */
if (ELF_ST_BIND(sym->st_info) != STB_LOCAL)
continue;
- elf_reloc_local(lf, base, rela, ELF_RELOC_RELA
Linux process causes kernel panic
I've got similar panic right after skype start
Disabling of SMAP via loader tunable workarounded the panic for me.
Applying of the patch make skype eating 100%CPU in unkillable state.
tail of ktrace dump
1238 skype CALL linux_gettid
1238 skype RET linux_gettid 101123/0x18b03
1238 skype CALL
linux_sys_futex(0x3301edc,0x84,0x1,0x7fff,0x3301ec0,0x2)
1238 skype RET linux_sys_futex 0
1238 skype CALL linux_sys_futex(0x33b0fac,0x80,0x1,0,0x33b0f90,0x1)
1238 skype CALL linux_sys_futex(0x3301edc,0x80,0x1,0,0x3301ec0,0x1)
1238 skype RET linux_sys_futex -1 errno -11 Resource temporarily
unavailable
1238 skype CALL
linux_sys_futex(0x3301ec0,0x81,0x1,0x3301ec0,0x33b02c8,0xc168)
1238 skype RET linux_sys_futex 0
1238 skype CALL
linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401)
-- here it stops --
ddb also shows that process is looping somewhere inside linux_sys_futex()
KDB: enter: manual escape to
debugger
[ thread pid 11 tid 100014
]
Stopped at kdb_enter+0x3b: movq
$0,kdb_why
db> bt
1238
Tracing pid 1238 tid 101049 td
0xf80157a64000
cpustop_handler() at cpustop_handler+0x28/frame
0xfe9d6df0
ipi_nmi_handler() at ipi_nmi_handler+0x44/frame
0xfe9d6e10
trap() at trap+0x49/frame
0xfe9d6f20
nmi_calltrap() at nmi_calltrap+0x8/frame
0xfe9d6f20
--- trap 0x13, rip = 0x80709219, rsp = 0xfe00a8c906d0, rbp =
0xfe00a8c90750
---
witness_unlock() at witness_unlock+0x139/frame 0xfe00a8c90750
__mtx_unlock_flags() at __mtx_unlock_flags+0x5d/frame
0xfe00a8c90790
futex_put() at futex_put+0x134/frame
0xfe00a8c907c0
linux_sys_futex() at linux_sys_futex+0x609/frame
0xfe00a8c90880
ia32_syscall() at ia32_syscall+0x282/frame
0xfe00a8c909b0
int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
On 06.08.2018 15:03, Johannes Lundberg wrote:
> On Sat, Aug 4, 2018 at 3:22 PM Konstantin Belousov
> wrote:
>
>> On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
>>> No panic over night with that tunable so it seems you're on the right
>>> track.
>> Please try this, on top of r337316.
>>
> Been running boinc client now with 4 linux processes at 100% cpu load with
> this patch for a while. So far so good.
>
>
>> diff --git a/sys/amd64/linux/linux_machdep.c
>> b/sys/amd64/linux/linux_machdep.c
>> index 6c5b014853f..434ea0eac07 100644
>> --- a/sys/amd64/linux/linux_machdep.c
>> +++ b/sys/amd64/linux/linux_machdep.c
>> @@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>>
>> +#include
>> +#include
>> +
>> #include
>> #include
>> #include
>> @@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>>
>> -#include
>> -
>> int
>> linux_execve(struct thread *td, struct linux_execve_args *args)
>> {
>> @@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
>>
>> return (0);
>> }
>> +
>> +int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
>> +int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
>> +DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
>> +{
>> +
>> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
>> + futex_xchgl_smap : futex_xchgl_nosmap);
>> +}
>> +
>> +int futex_a
Re: Linux process causes kernel panic
On Sat, Aug 4, 2018 at 3:22 PM Konstantin Belousov
wrote:
> On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
> > No panic over night with that tunable so it seems you're on the right
> > track.
>
> Please try this, on top of r337316.
>
Been running boinc client now with 4 linux processes at 100% cpu load with
this patch for a while. So far so good.
> diff --git a/sys/amd64/linux/linux_machdep.c
> b/sys/amd64/linux/linux_machdep.c
> index 6c5b014853f..434ea0eac07 100644
> --- a/sys/amd64/linux/linux_machdep.c
> +++ b/sys/amd64/linux/linux_machdep.c
> @@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
> #include
> #include
>
> +#include
> +#include
> +
> #include
> #include
> #include
> @@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
> #include
> #include
>
> -#include
> -
> int
> linux_execve(struct thread *td, struct linux_execve_args *args)
> {
> @@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
>
> return (0);
> }
> +
> +int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
> +{
> +
> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> + futex_xchgl_smap : futex_xchgl_nosmap);
> +}
> +
> +int futex_addl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_addl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_addl, (int, uint32_t *, int *), static)
> +{
> +
> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> + futex_addl_smap : futex_addl_nosmap);
> +}
> +
> +int futex_orl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_orl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_orl, (int, uint32_t *, int *), static)
> +{
> +
> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> + futex_orl_smap : futex_orl_nosmap);
> +}
> +
> +int futex_andl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_andl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_andl, (int, uint32_t *, int *), static)
> +{
> +
> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> + futex_andl_smap : futex_andl_nosmap);
> +}
> +
> +int futex_xorl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_xorl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_xorl, (int, uint32_t *, int *), static)
> +{
> +
> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> + futex_xorl_smap : futex_xorl_nosmap);
> +}
> diff --git a/sys/amd64/linux/linux_support.s
> b/sys/amd64/linux/linux_support.s
> index a9f02160be2..391f76414f2 100644
> --- a/sys/amd64/linux/linux_support.s
> +++ b/sys/amd64/linux/linux_support.s
> @@ -38,7 +38,7 @@ futex_fault:
> movl$-EFAULT,%eax
> ret
>
> -ENTRY(futex_xchgl)
> +ENTRY(futex_xchgl_nosmap)
> movqPCPU(CURPCB),%r8
> movq$futex_fault,PCB_ONFAULT(%r8)
> movq$VM_MAXUSER_ADDRESS-4,%rax
> @@ -49,25 +49,58 @@ ENTRY(futex_xchgl)
> xorl%eax,%eax
> movq%rax,PCB_ONFAULT(%r8)
> ret
> -END(futex_xchgl)
> +END(futex_xchgl_nosmap)
>
> -ENTRY(futex_addl)
> +ENTRY(futex_xchgl_smap)
> movqPCPU(CURPCB),%r8
> movq$futex_fault,PCB_ONFAULT(%r8)
> movq$VM_MAXUSER_ADDRESS-4,%rax
> cmpq%rax,%rsi
> ja futex_fault
> + stac
> + xchgl %edi,(%rsi)
> + clac
> + movl%edi,(%rdx)
> + xorl%eax,%eax
> + movq%rax,PCB_ONFAULT(%r8)
> + ret
> +END(futex_xchgl_smap)
> +
> +ENTRY(futex_addl_nosmap)
> + movqPCPU(CURPCB),%r8
> + movq$futex_fault,PCB_ONFAULT(%r8)
> + movq$VM_MAXUSER_ADDRESS-4,%rax
> + cmpq%rax,%rsi
> + ja futex_fault
> +#ifdef SMP
> + lock
> +#endif
> + xaddl %edi,(%rsi)
> + movl%edi,(%rdx)
> + xorl%eax,%eax
> + movq%rax,PCB_ONFAULT(%r8)
> + ret
> +END(futex_addl_nosmap)
> +
> +ENTRY(futex_addl_smap)
> + movqPCPU(CURPCB),%r8
> + movq$futex_fault,PCB_ONFAULT(%r8)
> + movq$VM_MAXUSER_ADDRESS-4,%rax
> + cmpq%rax,%rsi
> + ja futex_fault
> + stac
> #ifdef SMP
> lock
> #endif
> xaddl %edi,(%rsi)
> + clac
> movl%edi,(%rdx)
> xorl%eax,%eax
> movq%rax,PCB_ONFAULT(%r8)
> ret
> -END(futex_addl)
> +END(futex_addl_smap)
>
> -ENTRY(futex_orl)
> +ENTRY(futex_orl_nosmap)
> movqPCPU(CURPCB),%r8
> movq$futex_fault,PCB_ONFAULT(%r8)
> movq$VM_MAXUSER_ADDRESS-4,%rax
> @@ -85,9 +118,31 @@ ENTRY(futex_orl)
> xorl%eax,%eax
> movq%rax,PCB_ONFAULT(%r8)
> ret
> -END(futex_orl)
> +END(futex_orl_nosmap)
>
> -ENTRY(futex_andl)
>
Re: Linux process causes kernel panic
On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
> No panic over night with that tunable so it seems you're on the right
> track.
Please try this, on top of r337316.
diff --git a/sys/amd64/linux/linux_machdep.c b/sys/amd64/linux/linux_machdep.c
index 6c5b014853f..434ea0eac07 100644
--- a/sys/amd64/linux/linux_machdep.c
+++ b/sys/amd64/linux/linux_machdep.c
@@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
+#include
+
#include
#include
#include
@@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#include
-
int
linux_execve(struct thread *td, struct linux_execve_args *args)
{
@@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
return (0);
}
+
+int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
+{
+
+ return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+ futex_xchgl_smap : futex_xchgl_nosmap);
+}
+
+int futex_addl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_addl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_addl, (int, uint32_t *, int *), static)
+{
+
+ return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+ futex_addl_smap : futex_addl_nosmap);
+}
+
+int futex_orl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_orl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_orl, (int, uint32_t *, int *), static)
+{
+
+ return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+ futex_orl_smap : futex_orl_nosmap);
+}
+
+int futex_andl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_andl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_andl, (int, uint32_t *, int *), static)
+{
+
+ return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+ futex_andl_smap : futex_andl_nosmap);
+}
+
+int futex_xorl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_xorl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_xorl, (int, uint32_t *, int *), static)
+{
+
+ return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+ futex_xorl_smap : futex_xorl_nosmap);
+}
diff --git a/sys/amd64/linux/linux_support.s b/sys/amd64/linux/linux_support.s
index a9f02160be2..391f76414f2 100644
--- a/sys/amd64/linux/linux_support.s
+++ b/sys/amd64/linux/linux_support.s
@@ -38,7 +38,7 @@ futex_fault:
movl$-EFAULT,%eax
ret
-ENTRY(futex_xchgl)
+ENTRY(futex_xchgl_nosmap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
@@ -49,25 +49,58 @@ ENTRY(futex_xchgl)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_xchgl)
+END(futex_xchgl_nosmap)
-ENTRY(futex_addl)
+ENTRY(futex_xchgl_smap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
cmpq%rax,%rsi
ja futex_fault
+ stac
+ xchgl %edi,(%rsi)
+ clac
+ movl%edi,(%rdx)
+ xorl%eax,%eax
+ movq%rax,PCB_ONFAULT(%r8)
+ ret
+END(futex_xchgl_smap)
+
+ENTRY(futex_addl_nosmap)
+ movqPCPU(CURPCB),%r8
+ movq$futex_fault,PCB_ONFAULT(%r8)
+ movq$VM_MAXUSER_ADDRESS-4,%rax
+ cmpq%rax,%rsi
+ ja futex_fault
+#ifdef SMP
+ lock
+#endif
+ xaddl %edi,(%rsi)
+ movl%edi,(%rdx)
+ xorl%eax,%eax
+ movq%rax,PCB_ONFAULT(%r8)
+ ret
+END(futex_addl_nosmap)
+
+ENTRY(futex_addl_smap)
+ movqPCPU(CURPCB),%r8
+ movq$futex_fault,PCB_ONFAULT(%r8)
+ movq$VM_MAXUSER_ADDRESS-4,%rax
+ cmpq%rax,%rsi
+ ja futex_fault
+ stac
#ifdef SMP
lock
#endif
xaddl %edi,(%rsi)
+ clac
movl%edi,(%rdx)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_addl)
+END(futex_addl_smap)
-ENTRY(futex_orl)
+ENTRY(futex_orl_nosmap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
@@ -85,9 +118,31 @@ ENTRY(futex_orl)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_orl)
+END(futex_orl_nosmap)
-ENTRY(futex_andl)
+ENTRY(futex_orl_smap)
+ movqPCPU(CURPCB),%r8
+ movq$futex_fault,PCB_ONFAULT(%r8)
+ movq$VM_MAXUSER_ADDRESS-4,%rax
+ cmpq%rax,%rsi
+ ja futex_fault
+ movl(%rsi),%eax
+1: movl%eax,%ecx
+ orl %edi,%ecx
+ stac
+#ifdef SMP
+ lock
+#endif
+ cmpxchgl %ecx,(%rsi)
+ clac
+ jnz 1b
+ movl%eax,(%rdx)
+ xorl%eax,%eax
+ movq%rax,PCB_ONFAULT(%r8)
+ ret
+
Re: Linux process causes kernel panic
On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov wrote: > On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote: > > Hi > > > > After install new kernel+world built from today's checkout I keep getting > > the same crash over and over. Never had this problem before. The previous > > kernel was from 3 weeks ago. > > > > Looks familiar to anyone? > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address= 0xfffe665c > > fault code= supervisor write data, protection violation > > instruction pointer= 0x20:0x82282db3 > > stack pointer= 0x0:0xfe004c74c8c8 > > frame pointer= 0x0:0xfe004c74c980 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process= 1579 (wcgrid_zika_vina_7.) > > trap number= 12 > > panic: page fault > > cpuid = 0 > > time = 1533327428 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe004c74c580 > > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 > > panic() at panic+0x43/frame 0xfe004c74c640 > > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 > > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 > > trap() at trap+0x2ba/frame 0xfe004c74c7f0 > > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 > > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = > > 0xfe004c74c980 --- > > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 > > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 > > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 > > Uptime: 7m29s > > Dumping 411 out of 8056 > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > > Dump complete > > Post first 40 lines from the verbose dmesg boot of your machine. > > I have a guess what is going on, I need the dmesg to confirm. > If my guess is correct, you can use a workaround by setting the > "hw.cpu_stdext_disable=0x0010" tunable at the loader prompt for now. > No panic over night with that tunable so it seems you're on the right track. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linux process causes kernel panic
On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov wrote: > On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote: > > Hi > > > > After install new kernel+world built from today's checkout I keep getting > > the same crash over and over. Never had this problem before. The previous > > kernel was from 3 weeks ago. > > > > Looks familiar to anyone? > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address= 0xfffe665c > > fault code= supervisor write data, protection violation > > instruction pointer= 0x20:0x82282db3 > > stack pointer= 0x0:0xfe004c74c8c8 > > frame pointer= 0x0:0xfe004c74c980 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process= 1579 (wcgrid_zika_vina_7.) > > trap number= 12 > > panic: page fault > > cpuid = 0 > > time = 1533327428 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe004c74c580 > > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 > > panic() at panic+0x43/frame 0xfe004c74c640 > > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 > > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 > > trap() at trap+0x2ba/frame 0xfe004c74c7f0 > > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 > > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = > > 0xfe004c74c980 --- > > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 > > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 > > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 > > Uptime: 7m29s > > Dumping 411 out of 8056 > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > > Dump complete > > Post first 40 lines from the verbose dmesg boot of your machine. > Table 'FACP' at 0xd970da80 Table 'APIC' at 0xd970db90 APIC: Found table at 0xd970db90 APIC: Using the MADT enumerator. Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #86 d2391fd58c4(master)-dirty: Fri Aug 3 10:57:46 BST 2018 root@jd:/usr/obj/usr/src/amd64.amd64/sys/JD amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xd970da80 Table 'APIC' at 0xd970db90 Table 'FPDT' at 0xd970dc18 Table 'FIDT' at 0xd970dc60 Table 'MCFG' at 0xd970dd00 Table 'HPET' at 0xd970dd40 Table 'SSDT' at 0xd970dd78 Table 'UEFI' at 0xd970e230 Table 'SSDT' at 0xd970e278 Table 'ASF!' at 0xd970eef8 Table 'SSDT' at 0xd970ef98 Table 'SSDT' at 0xd970f4b8 Table 'SSDT' at 0xd9710030 Table 'SSDT' at 0xd97101f8 Table 'PCCT' at 0xd97105a0 Table 'SSDT' at 0xd9710610 Table 'SSDT' at 0xd97110d8 Table 'SSDT' at 0xd9715288 Table 'SLIC' at 0xd9719790 Table 'MSDM' at 0xd9719908 Table 'DMAR' at 0xd9719960 Table 'BGRT' at 0xd9719a10 ACPI: No SRAT table found PPIM 0: PA=0xe000, VA=0x81a1, size=0x7e9000, mode=0x1 VT(efifb): resolution 1920x1080 Preloaded elf kernel "/boot/kernel.JD/kernel" at 0x8186c000. Preloaded boot_entropy_cache "/boot/entropy" at 0x81875e58. Preloaded elf obj module "/boot/kernel.JD/snd_hda.ko" at 0x81875eb0. Preloaded elf obj module "/boot/kernel.JD/ums.ko" at 0x81876560. Table 'FACP' at 0xd970da80 FACP: Found table at 0xd970da80 Calibrating TSC clock ... TSC clock: 2194965386 Hz CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (2194.97-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306d4 Family=0x6 Model=0x3d Stepping=4 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21c27ab XSAVE Features=0x1 VT-x: Basic Features=0xda0400 Pin-Based Controls=0x7f Primary Processor Controls=0xfff9fffe Secondary Processor Controls=0x53cff Exit Controls=0xda0400 Entry Controls=0xda0400 EPT Features=0x6334141 VPID Features=0xf01 TSC: P-state invariant, performance statistics Data TLB: 2 MByte or 4 MByte pages, 4-way set associative, 32 entries and a separate array with 1 GByte pages, 4-way set associative, 4 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M pages, fully associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 64 entries 64-Byte prefetching Shared 2nd-Level TLB: 4 KByte /2 MByte pages, 6-way associative, 1536 entries. Also 1GBbyte pages, 4-way, 16 entries L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0001 - 0x00057fff, 294
Re: Linux process causes kernel panic
On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote: > Hi > > After install new kernel+world built from today's checkout I keep getting > the same crash over and over. Never had this problem before. The previous > kernel was from 3 weeks ago. > > Looks familiar to anyone? > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address= 0xfffe665c > fault code= supervisor write data, protection violation > instruction pointer= 0x20:0x82282db3 > stack pointer= 0x0:0xfe004c74c8c8 > frame pointer= 0x0:0xfe004c74c980 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process= 1579 (wcgrid_zika_vina_7.) > trap number= 12 > panic: page fault > cpuid = 0 > time = 1533327428 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe004c74c580 > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 > panic() at panic+0x43/frame 0xfe004c74c640 > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 > trap() at trap+0x2ba/frame 0xfe004c74c7f0 > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = > 0xfe004c74c980 --- > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 > Uptime: 7m29s > Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > Dump complete Post first 40 lines from the verbose dmesg boot of your machine. I have a guess what is going on, I need the dmesg to confirm. If my guess is correct, you can use a workaround by setting the "hw.cpu_stdext_disable=0x0010" tunable at the loader prompt for now. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linux process causes kernel panic
On 8/3/18, Johannes Lundberg wrote: > On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter > > wrote: > >> Hi! >> >> On 8/3/18, Johannes Lundberg wrote: >> > Hi >> > >> > After install new kernel+world built from today's checkout I keep >> > getting >> > the same crash over and over. Never had this problem before. The >> > previous >> > kernel was from 3 weeks ago. >> > >> > Looks familiar to anyone? >> >> Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP >> support? >> > > This is Intel Broadwell, Core i5. The smapification of amd64/linux/linux_support.s is missing from the SMAP patch. CC kib@. > > >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address= 0xfffe665c >> > fault code= supervisor write data, protection violation >> > instruction pointer= 0x20:0x82282db3 >> > stack pointer= 0x0:0xfe004c74c8c8 >> > frame pointer= 0x0:0xfe004c74c980 >> > code segment= base 0x0, limit 0xf, type 0x1b >> > = DPL 0, pres 1, long 1, def32 0, gran 1 >> > processor eflags= interrupt enabled, resume, IOPL = 0 >> > current process= 1579 (wcgrid_zika_vina_7.) >> > trap number= 12 >> > panic: page fault >> > cpuid = 0 >> > time = 1533327428 >> > KDB: stack backtrace: >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> > 0xfe004c74c580 >> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 >> > panic() at panic+0x43/frame 0xfe004c74c640 >> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 >> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 >> > trap() at trap+0x2ba/frame 0xfe004c74c7f0 >> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 >> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = >> > 0xfe004c74c980 --- >> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 >> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 >> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 >> > Uptime: 7m29s >> > Dumping 411 out of 8056 >> > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% >> > Dump complete >> > ___ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to " >> freebsd-current-unsubscr...@freebsd.org" >> > >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linux process causes kernel panic
On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter wrote: > Hi! > > On 8/3/18, Johannes Lundberg wrote: > > Hi > > > > After install new kernel+world built from today's checkout I keep getting > > the same crash over and over. Never had this problem before. The previous > > kernel was from 3 weeks ago. > > > > Looks familiar to anyone? > > Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP > support? > This is Intel Broadwell, Core i5. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address= 0xfffe665c > > fault code= supervisor write data, protection violation > > instruction pointer= 0x20:0x82282db3 > > stack pointer= 0x0:0xfe004c74c8c8 > > frame pointer= 0x0:0xfe004c74c980 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process= 1579 (wcgrid_zika_vina_7.) > > trap number= 12 > > panic: page fault > > cpuid = 0 > > time = 1533327428 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe004c74c580 > > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 > > panic() at panic+0x43/frame 0xfe004c74c640 > > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 > > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 > > trap() at trap+0x2ba/frame 0xfe004c74c7f0 > > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 > > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = > > 0xfe004c74c980 --- > > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 > > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 > > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 > > Uptime: 7m29s > > Dumping 411 out of 8056 > > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > > Dump complete > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Linux process causes kernel panic
Hi! On 8/3/18, Johannes Lundberg wrote: > Hi > > After install new kernel+world built from today's checkout I keep getting > the same crash over and over. Never had this problem before. The previous > kernel was from 3 weeks ago. > > Looks familiar to anyone? Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP support? > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address= 0xfffe665c > fault code= supervisor write data, protection violation > instruction pointer= 0x20:0x82282db3 > stack pointer= 0x0:0xfe004c74c8c8 > frame pointer= 0x0:0xfe004c74c980 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process= 1579 (wcgrid_zika_vina_7.) > trap number= 12 > panic: page fault > cpuid = 0 > time = 1533327428 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe004c74c580 > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 > panic() at panic+0x43/frame 0xfe004c74c640 > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 > trap() at trap+0x2ba/frame 0xfe004c74c7f0 > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = > 0xfe004c74c980 --- > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 > Uptime: 7m29s > Dumping 411 out of 8056 > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% > Dump complete > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Linux process causes kernel panic
Hi After install new kernel+world built from today's checkout I keep getting the same crash over and over. Never had this problem before. The previous kernel was from 3 weeks ago. Looks familiar to anyone? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address= 0xfffe665c fault code= supervisor write data, protection violation instruction pointer= 0x20:0x82282db3 stack pointer= 0x0:0xfe004c74c8c8 frame pointer= 0x0:0xfe004c74c980 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 1579 (wcgrid_zika_vina_7.) trap number= 12 panic: page fault cpuid = 0 time = 1533327428 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe004c74c580 vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0 panic() at panic+0x43/frame 0xfe004c74c640 trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690 trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0 trap() at trap+0x2ba/frame 0xfe004c74c7f0 calltrap() at calltrap+0x8/frame 0xfe004c74c7f0 --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp = 0xfe004c74c980 --- futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980 ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0 int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401 Uptime: 7m29s Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94% Dump complete ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
