Re: Crash loading dtraceall
On Wed, May 08, 2019 at 11:01:58PM -0500, Larry Rosenman wrote:
> On 05/08/2019 10:32 pm, Mark Johnston wrote:
> > On Wed, May 08, 2019 at 05:57:18PM -0500, Larry Rosenman wrote:
> >> On 05/08/2019 5:55 pm, Mark Johnston wrote:
> >> > On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
> >> >> On 05/08/2019 5:29 pm, Mark Johnston wrote:
> >> >> > On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
> >> >> >> Greetings,
> >> >> >>
> >> >> >> Somewhere between r346483 and r347241 loading dtraceall causes a
> >> >> >> crash. I have the cores and kernels.
> >> >> >>
> >> >> >> It's hard for me to bisect more than this, as the box is remote.
> >> >> >>
> >> >> >> What more do you need? (this dump is fropm r347355).
> >> >> >
> > The problem is with the kernel linker's handling of ifuncs. When
> > enumerating symbols, it replaces ifunc symbol values with the return
> > value of the resolver but preserves the original symbol size, which is
> > that of the resolver. I believe this patch will address the panic
> > you're seeing:
> >
> It does *NOT*.
I see, my theory above is not the real problem here. The resolver for
x86_rng_store() may return NULL, which we do not expect. Can you show
the CPU info and features lines from the dmesg to confirm?
Also see if this patch helps:
diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c
index 57f3d0a1d80b..71065d788cf9 100644
--- a/sys/dev/random/ivy.c
+++ b/sys/dev/random/ivy.c
@@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf)
return (retry);
}
+static int
+x86_dead_store(u_long *buf __unused)
+{
+
+ panic("missing hardware PRNG support");
+}
+
DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static)
{
has_rdrand = (cpu_feature2 & CPUID2_RDRAND);
@@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf),
static)
else if (has_rdrand)
return (x86_rdrand_store);
else
- return (NULL);
+ return (x86_dead_store);
}
/* It is required that buf length is a multiple of sizeof(u_long). */
___
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: Crash loading dtraceall
On 05/08/2019 10:32 pm, Mark Johnston wrote:
On Wed, May 08, 2019 at 05:57:18PM -0500, Larry Rosenman wrote:
On 05/08/2019 5:55 pm, Mark Johnston wrote:
> On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
>> On 05/08/2019 5:29 pm, Mark Johnston wrote:
>> > On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
>> >> Greetings,
>> >>
>> >> Somewhere between r346483 and r347241 loading dtraceall causes a
>> >> crash. I have the cores and kernels.
>> >>
>> >> It's hard for me to bisect more than this, as the box is remote.
>> >>
>> >> What more do you need? (this dump is fropm r347355).
>> >
>> > Please visit frame 8 and print *lf.
>> >
>> #9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
>> symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
>> /usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
>> 191if (*instr == FBT_PUSHL_EBP)
>> (kgdb) print *lf
>> $1 = {ops = 0xf800020f6000, refs = 202, userrefs = 1, flags = 1,
>> link = {tqe_next = 0xf800020fec00, tqe_prev = 0x80c767d0
>> }, filename = 0xf80002101030 "kernel",
>>pathname = 0xf80002104080 "/boot/kernel/kernel", id = 1,
>> address =
>> 0x8020 "\177ELF\002\001\001\t", size = 17612816,
>> ctors_addr
>> = 0x0, ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first =
>> 0x0,
>> stqh_last = 0xf800020ff070}, modules = {tqh_first =
>> 0xf800020e5800, tqh_last = 0xf80002116790}, loaded = {tqe_next
>> =
>> 0x0, tqe_prev = 0x0}, loadcnt = 1, nenabled = 0, fbt_nentries = 25062}
>> (kgdb)
>
> And could you show the output of:
>
> $ readelf -s /boot/kernel/kernel | grep "30763:"
> ___
> 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"
[root@oldtbh2 /var/crash]# readelf -s /boot/kernel/kernel | grep
"30763:"
30763: 8079131075 IFUNC GLOBAL DEFAULT8
x86_rng_store
[root@oldtbh2 /var/crash]#
The problem is with the kernel linker's handling of ifuncs. When
enumerating symbols, it replaces ifunc symbol values with the return
value of the resolver but preserves the original symbol size, which is
that of the resolver. I believe this patch will address the panic
you're seeing:
diff --git a/sys/kern/link_elf.c b/sys/kern/link_elf.c
index 6ceb34d66b74..8bd9a0219a1d 100644
--- a/sys/kern/link_elf.c
+++ b/sys/kern/link_elf.c
@@ -1350,17 +1350,23 @@ static int
link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym,
linker_symval_t *symval)
{
+ c_linker_sym_t target;
elf_file_t ef;
const Elf_Sym *es;
caddr_t val;
+ long diff;
ef = (elf_file_t)lf;
es = (const Elf_Sym *)sym;
if (es >= ef->symtab && es < (ef->symtab + ef->nchains)) {
symval->name = ef->strtab + es->st_name;
val = (caddr_t)ef->address + es->st_value;
- if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC)
+ if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC) {
val = ((caddr_t (*)(void))val)();
+ (void)link_elf_search_symbol(lf, val, , );
+ if (diff == 0)
+ es = (const Elf_Sym *)target;
+ }
symval->value = val;
symval->size = es->st_size;
return (0);
@@ -1370,8 +1376,12 @@ link_elf_symbol_values(linker_file_t lf,
c_linker_sym_t sym,
if (es >= ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) {
symval->name = ef->ddbstrtab + es->st_name;
val = (caddr_t)ef->address + es->st_value;
- if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC)
+ if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC) {
val = ((caddr_t (*)(void))val)();
+ (void)link_elf_search_symbol(lf, val, , );
+ if (diff == 0)
+ es = (const Elf_Sym *)target;
+ }
symval->value = val;
symval->size = es->st_size;
return (0);
diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
index ac4cc8c085cb..5ce160a05699 100644
--- a/sys/kern/link_elf_obj.c
+++ b/sys/kern/link_elf_obj.c
@@ -1240,9 +1240,11 @@ static int
link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym,
linker_symval_t *symval)
{
+ c_linker_sym_t target;
elf_file_t ef;
const Elf_Sym *es;
caddr_t val;
+ long diff;
ef = (elf_file_t) lf;
es = (const Elf_Sym*) sym;
@@ -1250,8 +1252,12 @@ link_elf_symbol_values(linker_file_t lf,
c_linker_sym_t sym,
if (es >= ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) {
symval->name = ef->ddbstrtab + es->st_name;
val =
Re: Crash loading dtraceall
On Wed, May 08, 2019 at 05:57:18PM -0500, Larry Rosenman wrote:
> On 05/08/2019 5:55 pm, Mark Johnston wrote:
> > On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
> >> On 05/08/2019 5:29 pm, Mark Johnston wrote:
> >> > On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
> >> >> Greetings,
> >> >>
> >> >> Somewhere between r346483 and r347241 loading dtraceall causes a
> >> >> crash. I have the cores and kernels.
> >> >>
> >> >> It's hard for me to bisect more than this, as the box is remote.
> >> >>
> >> >> What more do you need? (this dump is fropm r347355).
> >> >
> >> > Please visit frame 8 and print *lf.
> >> >
> >> #9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
> >> symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
> >> /usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
> >> 191if (*instr == FBT_PUSHL_EBP)
> >> (kgdb) print *lf
> >> $1 = {ops = 0xf800020f6000, refs = 202, userrefs = 1, flags = 1,
> >> link = {tqe_next = 0xf800020fec00, tqe_prev = 0x80c767d0
> >> }, filename = 0xf80002101030 "kernel",
> >>pathname = 0xf80002104080 "/boot/kernel/kernel", id = 1,
> >> address =
> >> 0x8020 "\177ELF\002\001\001\t", size = 17612816,
> >> ctors_addr
> >> = 0x0, ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first =
> >> 0x0,
> >> stqh_last = 0xf800020ff070}, modules = {tqh_first =
> >> 0xf800020e5800, tqh_last = 0xf80002116790}, loaded = {tqe_next
> >> =
> >> 0x0, tqe_prev = 0x0}, loadcnt = 1, nenabled = 0, fbt_nentries = 25062}
> >> (kgdb)
> >
> > And could you show the output of:
> >
> > $ readelf -s /boot/kernel/kernel | grep "30763:"
> > ___
> > 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"
>
> [root@oldtbh2 /var/crash]# readelf -s /boot/kernel/kernel | grep
> "30763:"
> 30763: 8079131075 IFUNC GLOBAL DEFAULT8 x86_rng_store
> [root@oldtbh2 /var/crash]#
The problem is with the kernel linker's handling of ifuncs. When
enumerating symbols, it replaces ifunc symbol values with the return
value of the resolver but preserves the original symbol size, which is
that of the resolver. I believe this patch will address the panic
you're seeing:
diff --git a/sys/kern/link_elf.c b/sys/kern/link_elf.c
index 6ceb34d66b74..8bd9a0219a1d 100644
--- a/sys/kern/link_elf.c
+++ b/sys/kern/link_elf.c
@@ -1350,17 +1350,23 @@ static int
link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym,
linker_symval_t *symval)
{
+ c_linker_sym_t target;
elf_file_t ef;
const Elf_Sym *es;
caddr_t val;
+ long diff;
ef = (elf_file_t)lf;
es = (const Elf_Sym *)sym;
if (es >= ef->symtab && es < (ef->symtab + ef->nchains)) {
symval->name = ef->strtab + es->st_name;
val = (caddr_t)ef->address + es->st_value;
- if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC)
+ if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC) {
val = ((caddr_t (*)(void))val)();
+ (void)link_elf_search_symbol(lf, val, , );
+ if (diff == 0)
+ es = (const Elf_Sym *)target;
+ }
symval->value = val;
symval->size = es->st_size;
return (0);
@@ -1370,8 +1376,12 @@ link_elf_symbol_values(linker_file_t lf, c_linker_sym_t
sym,
if (es >= ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) {
symval->name = ef->ddbstrtab + es->st_name;
val = (caddr_t)ef->address + es->st_value;
- if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC)
+ if (ELF_ST_TYPE(es->st_info) == STT_GNU_IFUNC) {
val = ((caddr_t (*)(void))val)();
+ (void)link_elf_search_symbol(lf, val, , );
+ if (diff == 0)
+ es = (const Elf_Sym *)target;
+ }
symval->value = val;
symval->size = es->st_size;
return (0);
diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c
index ac4cc8c085cb..5ce160a05699 100644
--- a/sys/kern/link_elf_obj.c
+++ b/sys/kern/link_elf_obj.c
@@ -1240,9 +1240,11 @@ static int
link_elf_symbol_values(linker_file_t lf, c_linker_sym_t sym,
linker_symval_t *symval)
{
+ c_linker_sym_t target;
elf_file_t ef;
const Elf_Sym *es;
caddr_t val;
+ long diff;
ef = (elf_file_t) lf;
es = (const Elf_Sym*) sym;
@@ -1250,8 +1252,12 @@ link_elf_symbol_values(linker_file_t lf, c_linker_sym_t
sym,
if (es >= ef->ddbsymtab && es < (ef->ddbsymtab + ef->ddbsymcnt)) {
Re: Crash loading dtraceall
On 05/08/2019 5:55 pm, Mark Johnston wrote:
On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
On 05/08/2019 5:29 pm, Mark Johnston wrote:
> On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
>> Greetings,
>>
>> Somewhere between r346483 and r347241 loading dtraceall causes a
>> crash. I have the cores and kernels.
>>
>> It's hard for me to bisect more than this, as the box is remote.
>>
>> What more do you need? (this dump is fropm r347355).
>
> Please visit frame 8 and print *lf.
>
#9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
/usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
191 if (*instr == FBT_PUSHL_EBP)
(kgdb) print *lf
$1 = {ops = 0xf800020f6000, refs = 202, userrefs = 1, flags = 1,
link = {tqe_next = 0xf800020fec00, tqe_prev = 0x80c767d0
}, filename = 0xf80002101030 "kernel",
pathname = 0xf80002104080 "/boot/kernel/kernel", id = 1,
address =
0x8020 "\177ELF\002\001\001\t", size = 17612816,
ctors_addr
= 0x0, ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first =
0x0,
stqh_last = 0xf800020ff070}, modules = {tqh_first =
0xf800020e5800, tqh_last = 0xf80002116790}, loaded = {tqe_next
=
0x0, tqe_prev = 0x0}, loadcnt = 1, nenabled = 0, fbt_nentries = 25062}
(kgdb)
And could you show the output of:
$ readelf -s /boot/kernel/kernel | grep "30763:"
___
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"
[root@oldtbh2 /var/crash]# readelf -s /boot/kernel/kernel | grep
"30763:"
30763: 8079131075 IFUNC GLOBAL DEFAULT8 x86_rng_store
[root@oldtbh2 /var/crash]#
--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
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: Crash loading dtraceall
On Wed, May 08, 2019 at 05:47:08PM -0500, Larry Rosenman wrote:
> On 05/08/2019 5:29 pm, Mark Johnston wrote:
> > On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
> >> Greetings,
> >>
> >> Somewhere between r346483 and r347241 loading dtraceall causes a
> >> crash. I have the cores and kernels.
> >>
> >> It's hard for me to bisect more than this, as the box is remote.
> >>
> >> What more do you need? (this dump is fropm r347355).
> >
> > Please visit frame 8 and print *lf.
> >
> #9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
> symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
> /usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
> 191 if (*instr == FBT_PUSHL_EBP)
> (kgdb) print *lf
> $1 = {ops = 0xf800020f6000, refs = 202, userrefs = 1, flags = 1,
> link = {tqe_next = 0xf800020fec00, tqe_prev = 0x80c767d0
> }, filename = 0xf80002101030 "kernel",
>pathname = 0xf80002104080 "/boot/kernel/kernel", id = 1, address =
> 0x8020 "\177ELF\002\001\001\t", size = 17612816, ctors_addr
> = 0x0, ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first =
> 0x0,
> stqh_last = 0xf800020ff070}, modules = {tqh_first =
> 0xf800020e5800, tqh_last = 0xf80002116790}, loaded = {tqe_next =
> 0x0, tqe_prev = 0x0}, loadcnt = 1, nenabled = 0, fbt_nentries = 25062}
> (kgdb)
And could you show the output of:
$ readelf -s /boot/kernel/kernel | grep "30763:"
___
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: Crash loading dtraceall
On 05/08/2019 5:29 pm, Mark Johnston wrote:
On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
Greetings,
Somewhere between r346483 and r347241 loading dtraceall causes a
crash. I have the cores and kernels.
It's hard for me to bisect more than this, as the box is remote.
What more do you need? (this dump is fropm r347355).
Please visit frame 8 and print *lf.
(kgdb) bt
#0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:241
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:383
#2 0x80496320 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:470
#3 0x80496799 in vpanic (fmt=, ap=out>) at /usr/src/sys/kern/kern_shutdown.c:896
#4 0x804964d3 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:823
#5 0x80767314 in trap_fatal (frame=0xfe00d74d7cd0, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x80767379 in trap_pfault (frame=0xfe00d74d7cd0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:765
#7 0x80766964 in trap (frame=0xfe00d74d7cd0) at
/usr/src/sys/amd64/amd64/trap.c:441
#8
#9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
/usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
#10 0x804bf8f7 in link_elf_each_function_nameval
(file=0xf800020ff000, callback=0x825cb570
, opaque=0xfe00d74d7e50) at
/usr/src/sys/kern/link_elf.c:1513
#11 0x825ca33e in fbt_provide_module (arg=,
lf=0xf800020ff000) at /usr/src/sys/cddl/dev/fbt/fbt.c:204
#12 0x825ca242 in fbt_linker_file_cb (lf=0x825cbe45,
arg=0x812c9541) at /usr/src/sys/cddl/dev/fbt/fbt.c:1103
#13 0x8046d772 in linker_file_foreach
(predicate=0x825ca230 , context=0x0) at
/usr/src/sys/kern/kern_linker.c:594
#14 0x8046cb58 in linker_file_sysinit (lf=0xf80002a5da00) at
/usr/src/sys/kern/kern_linker.c:236
#15 linker_load_file (filename=, result=)
at /usr/src/sys/kern/kern_linker.c:462
#16 linker_load_module (kldname=,
modname=0x81d792ae "fbt", parent=,
verinfo=, lfpp=0x0) at
/usr/src/sys/kern/kern_linker.c:2110
#17 0x8046f1bd in linker_load_dependencies
(lf=0xf8002389a400) at /usr/src/sys/kern/kern_linker.c:2200
#18 0x80797f3e in link_elf_load_file (cls=,
filename=0xf80003d592c0 "/boot/kernel/dtraceall.ko",
result=0xfe00d74d8898) at /usr/src/sys/kern/link_elf_obj.c:1010
#19 0x8046c96f in LINKER_LOAD_FILE (cls=0x80a0
, filename=, result=0x0) at
./linker_if.h:180
#20 linker_load_file (filename=, result=)
at /usr/src/sys/kern/kern_linker.c:447
#21 linker_load_module (kldname=,
modname=0xf800231a7800 "dtraceall", parent=,
verinfo=, lfpp=0xfe00d74d8a38) at
/usr/src/sys/kern/kern_linker.c:2110
#22 0x8046e297 in kern_kldload (td=0xf80114df9000,
file=, fileid=0xfe00d74d8a74) at
/usr/src/sys/kern/kern_linker.c:1089
#23 0x8046e35b in sys_kldload (td=0xf80114df9000,
uap=) at /usr/src/sys/kern/kern_linker.c:1115
#24 0x80767ddc in syscallenter (td=0xf80114df9000) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#25 amd64_syscall (td=0xf80114df9000, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1166
#26
#27 0x0008002de43a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe658
(kgdb) fr 9
#9 fbt_provide_module_function (lf=0xf800020ff000, symindx=30763,
symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50) at
/usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:191
191 if (*instr == FBT_PUSHL_EBP)
(kgdb) print *lf
$1 = {ops = 0xf800020f6000, refs = 202, userrefs = 1, flags = 1,
link = {tqe_next = 0xf800020fec00, tqe_prev = 0x80c767d0
}, filename = 0xf80002101030 "kernel",
pathname = 0xf80002104080 "/boot/kernel/kernel", id = 1, address =
0x8020 "\177ELF\002\001\001\t", size = 17612816, ctors_addr
= 0x0, ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first =
0x0,
stqh_last = 0xf800020ff070}, modules = {tqh_first =
0xf800020e5800, tqh_last = 0xf80002116790}, loaded = {tqe_next =
0x0, tqe_prev = 0x0}, loadcnt = 1, nenabled = 0, fbt_nentries = 25062}
(kgdb)
--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
___
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: Crash loading dtraceall
On Wed, May 08, 2019 at 03:52:45PM -0500, Larry Rosenman wrote:
> Greetings,
>
> Somewhere between r346483 and r347241 loading dtraceall causes a
> crash. I have the cores and kernels.
>
> It's hard for me to bisect more than this, as the box is remote.
>
> What more do you need? (this dump is fropm r347355).
Please visit frame 8 and print *lf.
> Loaded symbols for /boot/kernel/fbt.ko
> #0 doadump (textdump=1) at src/sys/amd64/include/pcpu.h:241
> 241 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
> (OFFSETOF_CURTHREAD));
> (kgdb) #0 doadump (textdump=1) at src/sys/amd64/include/pcpu.h:241
> #1 0x80496320 in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:470
> #2 0x80496799 in vpanic (fmt=,
> ap=) at /usr/src/sys/kern/kern_shutdown.c:896
> #3 0x804964d3 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:823
> #4 0x80767314 in trap_fatal (frame=0xfe00d74d7cd0, eva=0)
> at /usr/src/sys/amd64/amd64/trap.c:946
> #5 0x80767379 in trap_pfault (frame=0xfe00d74d7cd0, usermode=0)
> at src/sys/amd64/include/pcpu.h:241
> #6 0x80766964 in trap (frame=0xfe00d74d7cd0)
> at /usr/src/sys/amd64/amd64/trap.c:441
> #7 0x80740805 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:232
> #8 0x825cb5ea in fbt_provide_module_function (lf=0xf800020ff000,
> symindx=30763, symval=0xfe00d74d7e00, opaque=0xfe00d74d7e50)
> at /usr/src/sys/cddl/dev/fbt/x86/fbt_isa.c:190
> #9 0x804bf8f7 in link_elf_each_function_nameval (
> file=0xf800020ff000,
> callback=0x825cb570 ,
> opaque=0xfe00d74d7e50) at /usr/src/sys/kern/link_elf.c:1513
> #10 0x825ca33e in fbt_provide_module (arg=,
> lf=0xf800020ff000) at /usr/src/sys/cddl/dev/fbt/fbt.c:204
> #11 0x825ca242 in fbt_linker_file_cb (lf=,
> arg=) at /usr/src/sys/cddl/dev/fbt/fbt.c:1103
> #12 0x8046d772 in linker_file_foreach (
> predicate=0x825ca230 , context=0x0)
> at /usr/src/sys/kern/kern_linker.c:594
> #13 0x8046cb58 in linker_load_module (kldname=,
> modname=0x81d792ae "fbt", parent=,
> verinfo=, lfpp=0x0)
> at /usr/src/sys/kern/kern_linker.c:236
> #14 0x8046f1bd in linker_load_dependencies (lf=0xf8002389a400)
> at /usr/src/sys/kern/kern_linker.c:2200
> #15 0x80797f3e in link_elf_load_file (cls=,
> filename=0xf80003d592c0 "/boot/kernel/dtraceall.ko",
> result=0xfe00d74d8898) at /usr/src/sys/kern/link_elf_obj.c:1010
> #16 0x8046c96f in linker_load_module (kldname=,
> modname=0xf800231a7800 "dtraceall", parent=,
> verinfo=, lfpp=0xfe00d74d8a38) at linker_if.h:180
> #17 0x8046e297 in kern_kldload (td=0xf80114df9000,
> file=, fileid=0xfe00d74d8a74)
> at /usr/src/sys/kern/kern_linker.c:1089
> #18 0x8046e35b in sys_kldload (td=0xf80114df9000,
> uap=) at /usr/src/sys/kern/kern_linker.c:1115
> #19 0x80767ddc in amd64_syscall (td=0xf80114df9000, traced=0)
> at src/sys/amd64/amd64/../../kern/subr_syscall.c:135
> #20 0x807410ed in fast_syscall_common ()
> at /usr/src/sys/amd64/amd64/exception.S:504
> #21 0x0008002de43a in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language: auto; currently minimal
> (kgdb)
> --
> Larry Rosenman https://people.FreeBSD.org/~ler/
> Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
> US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
___
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"
Crash loading dtraceall
Greetings, Somewhere between r346483 and r347241 loading dtraceall causes a crash. I have the cores and kernels. It's hard for me to bisect more than this, as the box is remote. What more do you need? (this dump is fropm r347355). [l...@oldtbh2.lerctr.org:/var/crash] $ more core.txt.5 oldtbh2.lerctr.org dumped core - see /var/crash/vmcore.5 Wed May 8 15:46:58 CDT 2019 FreeBSD oldtbh2.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r347355 LER-MINIMAL amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x0 fault code = supervisor read data , page not present instruction pointer = 0x20:0x825cb5ea stack pointer = 0x28:0xfe00d74d7d90 frame pointer = 0x28:0xfe00d74d7df0 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 = 1531 (kldload) trap number = 12 panic: page fault cpuid = 3 time = 1557348131 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00d74d7a40 vpanic() at vpanic+0x19d/frame 0xfe00d74d7a90 panic() at panic+0x43/frame 0xfe00d74d7af0 trap_fatal() at trap_fatal+0x394/frame 0xfe00d74d7b50 trap_pfault() at trap_pfault+0x49/frame 0xfe00d74d7bb0 trap() at trap+0x2b4/frame 0xfe00d74d7cc0 calltrap() at calltrap+0x8/frame 0xfe00d74d7cc0 --- trap 0xc, rip = 0x825cb5ea, rsp = 0xfe00d74d7d90, rbp = 0xfe00d74d7df0 --- fbt_provide_module_function() at fbt_provide_module_function+0x7a/frame 0xfe00d74d7df0 link_elf_each_function_nameval() at link_elf_each_function_nameval+0xf7/frame 0xfe00d74d7e40 fbt_provide_module() at fbt_provide_module+0xde/frame 0xfe00d74d8270 fbt_linker_file_cb() at fbt_linker_file_cb+0x12/frame 0xfe00d74d8280 linker_file_foreach() at linker_file_foreach+0x52/frame 0xfe00d74d82b0 linker_load_module() at linker_load_module+0xbd8/frame 0xfe00d74d85e0 linker_load_dependencies() at linker_load_dependencies+0x2fd/frame 0xfe00d74d8630 link_elf_load_file() at link_elf_load_file+0x105e/frame 0xfe00d74d86f0 linker_load_module() at linker_load_module+0x9ef/frame 0xfe00d74d8a20 kern_kldload() at kern_kldload+0xa7/frame 0xfe00d74d8a60 sys_kldload() at sys_kldload+0x5b/frame 0xfe00d74d8a90 amd64_syscall() at amd64_syscall+0x25c/frame 0xfe00d74d8bb0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00d74d8bb0 --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002de43a, rsp = 0x7fffe658, rbp = 0x7fffebd0 --- Uptime: 2m40s Dumping 2258 out of 64482 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /usr/lib/debug//boot/kernel/krpc.ko.debug...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/if_em.ko...Reading symbols from /usr/lib/debug//boot/kernel/if_em.ko.debug...done. done. Loaded symbols for /boot/kernel/if_em.ko Reading symbols from /boot/kernel/iflib.ko...Reading symbols from /usr/lib/debug//boot/kernel/iflib.ko.debug...done. done. Loaded symbols for /boot/kernel/iflib.ko Reading symbols from /boot/kernel/if_bce.ko...Reading symbols from /usr/lib/debug//boot/kernel/if_bce.ko.debug...done. done. Loaded symbols for /boot/kernel/if_bce.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /usr/lib/debug//boot/kernel/miibus.ko.debug...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /usr/lib/debug//boot/kernel/coretemp.ko.debug...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/filemon.ko...Reading symbols from /usr/lib/debug//boot/kernel/filemon.ko.debug...done. done. Loaded symbols for /boot/kernel/filemon.ko Reading symbols from /boot/kernel/fuse.ko...Reading symbols from /usr/lib/debug//boot/kernel/fusefs.ko.debug...done. done. Loaded symbols for /boot/kernel/fuse.ko Reading symbols from
Re: Elantech touchpad (HID over I2C): any work planned?
W dniu 08.05.2019 o 18:54, Nikola Lečić pisze: > Hi, > > After buying a new Asus Zenbook 14 UX410UFR, I was unpleasantly > surprised that its touchpad (Elantech over I2C) isn't supported under > FreeBSD. > > I see that this kind of problem was discussed several times in the past: > https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069704.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2017-August/013617.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2016-March/013370.html > https://lists.freebsd.org/pipermail/freebsd-mobile/2016-November/013577.html > > OpenBSD's imt(4) driver detects this touchpad, and it works normally. > Please find the relevant info below. > > Can someone tell us if any kind of work on porting imt(4) driver (or > writing FreeBSD's own from scratch) is planned? Or it's better to > return this laptop and buy another one? > > OpenBSD dmesg: > > May 8 15:23:29 thorium /bsd: dwiic0 at pci0 dev 21 function 0 "Intel 100 > Series I2C" rev 0x21: apic 2 int 16 > May 8 15:23:29 thorium /bsd: iic0 at dwiic0 > May 8 15:23:29 thorium /bsd: dwiic1 at pci0 dev 21 function 1 "Intel 100 > Series I2C" rev 0x21: apic 2 int 17 > May 8 15:23:29 thorium /bsd: iic1 at dwiic1 > May 8 15:23:29 thorium /bsd: ihidev0 at iic1 addr 0x15 (polling), vendor > 0x4f3 product 0x309c, ELAN1200 > May 8 15:23:29 thorium /bsd: ihidev0: 11 report ids > May 8 15:23:29 thorium /bsd: imt0 at ihidev0: clickpad, 5 contacts > May 8 15:23:29 thorium /bsd: wsmouse0 at imt0 mux 0 > May 8 15:23:29 thorium /bsd: "Intel 100 Series I2C" rev 0x21 at pci0 dev 21 > function 2 not configured > May 8 15:23:29 thorium /bsd: "Intel 100 Series MEI" rev 0x21 at pci0 dev 22 > function 0 not configured > > Linux Xorg.0.log: > > [22.259] (II) config/udev: Adding input device ELAN1200:00 04F3:309C > Touchpad (/dev/input/event9) > [22.259] (**) ELAN1200:00 04F3:309C Touchpad: Applying InputClass > "libinput touchpad catchall" > [22.259] (II) Using input driver 'libinput' for 'ELAN1200:00 04F3:309C > Touchpad' > [22.259] (**) ELAN1200:00 04F3:309C Touchpad: always reports core events > [22.259] (**) Option "Device" "/dev/input/event9" > > Linux dmesg: > > [ 18.700018] input: ELAN1200:00 04F3:309C Touchpad as > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-9/i2c-ELAN1200:00/0018:04F3:309C.0001/input/input10 > [ 18.700101] hid-multitouch 0018:04F3:309C.0001: input,hidraw0: I2C HID > v1.00 Mouse [ELAN1200:00 04F3:309C] on i2c-ELAN1200:00 > Please follow the thread on the phabricator: https://reviews.freebsd.org/D16698 It's still work in progress, but works fine for me (not counting the fact that it broke suspend/resume). -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Elantech touchpad (HID over I2C): any work planned?
Hi, After buying a new Asus Zenbook 14 UX410UFR, I was unpleasantly surprised that its touchpad (Elantech over I2C) isn't supported under FreeBSD. I see that this kind of problem was discussed several times in the past: https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069704.html https://lists.freebsd.org/pipermail/freebsd-mobile/2017-August/013617.html https://lists.freebsd.org/pipermail/freebsd-mobile/2016-March/013370.html https://lists.freebsd.org/pipermail/freebsd-mobile/2016-November/013577.html OpenBSD's imt(4) driver detects this touchpad, and it works normally. Please find the relevant info below. Can someone tell us if any kind of work on porting imt(4) driver (or writing FreeBSD's own from scratch) is planned? Or it's better to return this laptop and buy another one? OpenBSD dmesg: May 8 15:23:29 thorium /bsd: dwiic0 at pci0 dev 21 function 0 "Intel 100 Series I2C" rev 0x21: apic 2 int 16 May 8 15:23:29 thorium /bsd: iic0 at dwiic0 May 8 15:23:29 thorium /bsd: dwiic1 at pci0 dev 21 function 1 "Intel 100 Series I2C" rev 0x21: apic 2 int 17 May 8 15:23:29 thorium /bsd: iic1 at dwiic1 May 8 15:23:29 thorium /bsd: ihidev0 at iic1 addr 0x15 (polling), vendor 0x4f3 product 0x309c, ELAN1200 May 8 15:23:29 thorium /bsd: ihidev0: 11 report ids May 8 15:23:29 thorium /bsd: imt0 at ihidev0: clickpad, 5 contacts May 8 15:23:29 thorium /bsd: wsmouse0 at imt0 mux 0 May 8 15:23:29 thorium /bsd: "Intel 100 Series I2C" rev 0x21 at pci0 dev 21 function 2 not configured May 8 15:23:29 thorium /bsd: "Intel 100 Series MEI" rev 0x21 at pci0 dev 22 function 0 not configured Linux Xorg.0.log: [22.259] (II) config/udev: Adding input device ELAN1200:00 04F3:309C Touchpad (/dev/input/event9) [22.259] (**) ELAN1200:00 04F3:309C Touchpad: Applying InputClass "libinput touchpad catchall" [22.259] (II) Using input driver 'libinput' for 'ELAN1200:00 04F3:309C Touchpad' [22.259] (**) ELAN1200:00 04F3:309C Touchpad: always reports core events [22.259] (**) Option "Device" "/dev/input/event9" Linux dmesg: [ 18.700018] input: ELAN1200:00 04F3:309C Touchpad as /devices/pci:00/:00:15.1/i2c_designware.1/i2c-9/i2c-ELAN1200:00/0018:04F3:309C.0001/input/input10 [ 18.700101] hid-multitouch 0018:04F3:309C.0001: input,hidraw0: I2C HID v1.00 Mouse [ELAN1200:00 04F3:309C] on i2c-ELAN1200:00 -- Nikola Lečić = Никола Лечић : https://www.hse.ru/staff/ndlecic fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ___ 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: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.
> On 8. May 2019, at 18:13, Andrey V. Elsukov wrote: > > Hi, > > today I updated one of my test machines and discovered that message from > the subject periodically printed in the console. Fixed in https://svnweb.freebsd.org/changeset/base/347329 Best regards Michael > > FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64 > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > LLVM 8.0.0) > VT(vga): resolution 640x480 > CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU) > ... > real memory = 68719476736 (65536 MB) > avail memory = 66722340864 (63631 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs > FreeBSD/SMP: 2 package(s) x 14 core(s) > ... > > % grep -c random /var/run/dmesg.boot > 606 > > % grep random /var/run/dmesg.boot | head -10 > __stack_chk_init: WARNING: Initializing stack protection with non-random > cookies! > random: entropy device external interface > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > arc4random: WARNING: initial seeding bypassed the cryptographic random > device because it was not yet seeded and the knob > 'bypass_before_seeding' was enabled. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > > % sysctl -a | grep -v random_sources_feed | grep rand > kern.fallback_elf_brand: -1 > devicerandom > devicerdrand_rng > kern.randompid: 0 > kern.elf32.fallback_brand: -1 > kern.elf64.fallback_brand: -1 > kern.random.fortuna.minpoolsize: 64 > kern.random.harvest.mask_symbolic: > PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > kern.random.harvest.mask_bin: 000100011101 > kern.random.harvest.mask: 66015 > kern.random.use_chacha20_cipher: 0 > kern.random.block_seeded_status: 0 > kern.random.random_sources: 'Intel Secure Key RNG' > kern.random.initial_seeding.disable_bypass_warnings: 0 > kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1 > kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 > kern.random.initial_seeding.bypass_before_seeding: 1 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.random_id_total: 0 > net.inet.ip.random_id_collisions: 0 > net.inet.ip.random_id_period: 0 > net.inet.ip.random_id: 0 > net.key.int_random: 60 > debug.fail_point.status_fill_kinfo_vnode__random_path: off > debug.fail_point.fill_kinfo_vnode__random_path: off > debug.fail_point.status_random_fortuna_pre_read: off > debug.fail_point.random_fortuna_pre_read: off > security.stack_protect.permit_nonrandom_cookies: 1 > > -- > WBR, Andrey V. Elsukov > smime.p7s Description: S/MIME cryptographic signature
Re: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.
Sorry about that. Please update to r347329. Thanks, Conrad On Wed, May 8, 2019 at 9:16 AM Andrey V. Elsukov wrote: > Hi, > > today I updated one of my test machines and discovered that message from > the subject periodically printed in the console. > > FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64 > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > LLVM 8.0.0) > VT(vga): resolution 640x480 > CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU) > ... > real memory = 68719476736 (65536 MB) > avail memory = 66722340864 (63631 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs > FreeBSD/SMP: 2 package(s) x 14 core(s) > ... > > % grep -c random /var/run/dmesg.boot > 606 > > % grep random /var/run/dmesg.boot | head -10 > __stack_chk_init: WARNING: Initializing stack protection with non-random > cookies! > random: entropy device external interface > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > arc4random: WARNING: initial seeding bypassed the cryptographic random > device because it was not yet seeded and the knob > 'bypass_before_seeding' was enabled. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' > returned no entropy. > > % sysctl -a | grep -v random_sources_feed | grep rand > kern.fallback_elf_brand: -1 > device random > device rdrand_rng > kern.randompid: 0 > kern.elf32.fallback_brand: -1 > kern.elf64.fallback_brand: -1 > kern.random.fortuna.minpoolsize: 64 > kern.random.harvest.mask_symbolic: > > PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > kern.random.harvest.mask_bin: 000100011101 > kern.random.harvest.mask: 66015 > kern.random.use_chacha20_cipher: 0 > kern.random.block_seeded_status: 0 > kern.random.random_sources: 'Intel Secure Key RNG' > kern.random.initial_seeding.disable_bypass_warnings: 0 > kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1 > kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 > kern.random.initial_seeding.bypass_before_seeding: 1 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.random_id_total: 0 > net.inet.ip.random_id_collisions: 0 > net.inet.ip.random_id_period: 0 > net.inet.ip.random_id: 0 > net.key.int_random: 60 > debug.fail_point.status_fill_kinfo_vnode__random_path: off > debug.fail_point.fill_kinfo_vnode__random_path: off > debug.fail_point.status_random_fortuna_pre_read: off > debug.fail_point.random_fortuna_pre_read: off > security.stack_protect.permit_nonrandom_cookies: 1 > > -- > WBR, Andrey V. Elsukov > > ___ 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: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.
On Wed, 2019-05-08 at 19:13 +0300, Andrey V. Elsukov wrote: > Hi, > > today I updated one of my test machines and discovered that message > from > the subject periodically printed in the console. > > FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64 > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on > LLVM 8.0.0) > VT(vga): resolution 640x480 > CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class > CPU) > ... > real memory = 68719476736 (65536 MB) > avail memory = 66722340864 (63631 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs > FreeBSD/SMP: 2 package(s) x 14 core(s) > ... > > % grep -c random /var/run/dmesg.boot > 606 > > % grep random /var/run/dmesg.boot | head -10 > __stack_chk_init: WARNING: Initializing stack protection with non- > random > cookies! > random: entropy device external interface > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > arc4random: WARNING: initial seeding bypassed the cryptographic > random > device because it was not yet seeded and the knob > 'bypass_before_seeding' was enabled. > random_sources_feed: rs_read for hardware device 'Intel Secure Key > RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key > RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key > RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key > RNG' > returned no entropy. > random_sources_feed: rs_read for hardware device 'Intel Secure Key > RNG' > returned no entropy. > > % sysctl -a | grep -v random_sources_feed | grep rand > kern.fallback_elf_brand: -1 > devicerandom > devicerdrand_rng > kern.randompid: 0 > kern.elf32.fallback_brand: -1 > kern.elf64.fallback_brand: -1 > kern.random.fortuna.minpoolsize: 64 > kern.random.harvest.mask_symbolic: > PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN > ,MOUSE,KEYBOARD,ATTACH,CACHED > kern.random.harvest.mask_bin: 000100011101 > kern.random.harvest.mask: 66015 > kern.random.use_chacha20_cipher: 0 > kern.random.block_seeded_status: 0 > kern.random.random_sources: 'Intel Secure Key RNG' > kern.random.initial_seeding.disable_bypass_warnings: 0 > kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1 > kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 > kern.random.initial_seeding.bypass_before_seeding: 1 > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.random_id_total: 0 > net.inet.ip.random_id_collisions: 0 > net.inet.ip.random_id_period: 0 > net.inet.ip.random_id: 0 > net.key.int_random: 60 > debug.fail_point.status_fill_kinfo_vnode__random_path: off > debug.fail_point.fill_kinfo_vnode__random_path: off > debug.fail_point.status_random_fortuna_pre_read: off > debug.fail_point.random_fortuna_pre_read: off > security.stack_protect.permit_nonrandom_cookies: 1 > Fixed in r347329. --Ian ___ 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"
random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.
Hi, today I updated one of my test machines and discovered that message from the subject periodically printed in the console. FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU) ... real memory = 68719476736 (65536 MB) avail memory = 66722340864 (63631 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs FreeBSD/SMP: 2 package(s) x 14 core(s) ... % grep -c random /var/run/dmesg.boot 606 % grep random /var/run/dmesg.boot | head -10 __stack_chk_init: WARNING: Initializing stack protection with non-random cookies! random: entropy device external interface random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. % sysctl -a | grep -v random_sources_feed | grep rand kern.fallback_elf_brand: -1 device random device rdrand_rng kern.randompid: 0 kern.elf32.fallback_brand: -1 kern.elf64.fallback_brand: -1 kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 000100011101 kern.random.harvest.mask: 66015 kern.random.use_chacha20_cipher: 0 kern.random.block_seeded_status: 0 kern.random.random_sources: 'Intel Secure Key RNG' kern.random.initial_seeding.disable_bypass_warnings: 0 kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1 kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 kern.random.initial_seeding.bypass_before_seeding: 1 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.random_id_total: 0 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_period: 0 net.inet.ip.random_id: 0 net.key.int_random: 60 debug.fail_point.status_fill_kinfo_vnode__random_path: off debug.fail_point.fill_kinfo_vnode__random_path: off debug.fail_point.status_random_fortuna_pre_read: off debug.fail_point.random_fortuna_pre_read: off security.stack_protect.permit_nonrandom_cookies: 1 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
12-STABLE/CURRENT: Dell PowerEdge 2950: Allied Telesis AT-2711FX/SC 100MBit fibre NIC not recognized
Hello, running FreeBSD 12-STABLE and FreeBSD 11.2 (OPNsense 19.X) on PowerEdge 2950 server systems (BIOS/Firmware 2.3.1 as of 2013), Allied Telesis AT-2711FX/SC PCIe 1x Nics are not recognized even by the BIOS/Firmware/hardware as there is neither a "none@busX" entry popping up when examinating via pciconf() the presence of hardware nor does FreeBSD report any recognized or not recognized devices of that kind. I'm not sure whether those fibre NICs of Allied Telesis (AT-2711FX/SC) are supported antway by FreeBSD, but I though until now if FreeBSD doesn't have a clue on a device, it would bring up a "none@" message in pciconf reporting hardware recognized by the firmare/base system but not the OS. Am I wrong here? I haven't tested those NICs in more modern hardware as the boxes are on a remote site, so it takes time to test, therfor, I asked here first. I need supported fibre NICs for both 100 MBit and 1GBit for FreeBSD 11 as well as 12 and if there is a suggestion, please, I'm open to it. Thanks in advance, O. Hartmann ___ 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"
