Re: Crash loading dtraceall

2019-05-09 Thread Larry Rosenman 

On 05/08/2019 11:31 pm, Mark Johnston wrote:

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). */


The above patch (on top of the previous one) fixes the crash.

flags/features as requested:
CPU: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz (2826.30-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
  
Features=0xbfebfbff
  
Features2=0xc0ce3bd

  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics


--
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

2019-05-08 Thread Mark Johnston 
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

2019-05-08 Thread Larry Rosenman 

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, &target, &diff);
+   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, &target, &diff);
+   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;

Re: Crash loading dtraceall

2019-05-08 Thread Mark Johnston 
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, &target, &diff);
+   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, &target, &diff);
+   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

2019-05-08 Thread Larry Rosenman 

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

2019-05-08 Thread Mark Johnston 
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

2019-05-08 Thread Larry Rosenman 

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

2019-05-08 Thread Mark Johnston 
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"