Re: Fwd: ZFS Crash/Pool in unhealthy state

2019-06-17 Thread Larry Rosenman

On 06/17/2019 10:33 am, Larry Rosenman wrote:

On 06/17/2019 10:31 am, Kurt Jaeger wrote:

Hi!


the drives are fine.

If I import the pool readonly, zpool status is also fine.

https://www.lerctr.org/~ler/ZFS_STATUS.png


Interesting. Which version of FreeBSD is this box running ?

-CURRENT.  From  Sunday.  And the recovery is running from the 6/14
Snap Memstick image.

to be specific the system is at R349093


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Fwd: ZFS Crash/Pool in unhealthy state

2019-06-17 Thread Larry Rosenman

On 06/17/2019 10:31 am, Kurt Jaeger wrote:

Hi!


the drives are fine.

If I import the pool readonly, zpool status is also fine.

https://www.lerctr.org/~ler/ZFS_STATUS.png


Interesting. Which version of FreeBSD is this box running ?
-CURRENT.  From  Sunday.  And the recovery is running from the 6/14 Snap 
Memstick image.



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Fwd: ZFS Crash/Pool in unhealthy state

2019-06-17 Thread Larry Rosenman

On 06/17/2019 9:53 am, Kurt Jaeger wrote:

Hi!


Forwarding to -Current as well, since it's a -current box


What is the status of the drives ? zpool status ?

There's a crash recovery tool, if all else fails:

https://www.klennet.com/zfs-recovery/default.aspx


the drives are fine.

If I import the pool readonly, zpool status is also fine.

https://www.lerctr.org/~ler/ZFS_STATUS.png


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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"


Fwd: ZFS Crash/Pool in unhealthy state

2019-06-17 Thread Larry Rosenman

Forwarding to -Current as well, since it's a -current box

 Original Message 
Subject: ZFS Crash/Pool in unhealthy state
Date: 06/17/2019 8:30 am
From: Larry Rosenman 
To: Freebsd fs 

I had a power failure today and my big server no longer boots

If I try to import the pool using the memstick image and -F -f I get a 
panic (see  link).


https://www.lerctr.org/~ler/ZFS_CRASH.png <--- Panic

https://www.lerctr.org/~ler/ZFS_IMPORT.png <--- import tries.

Ideas?  Help?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Panic in fbt_provide_module_function() on head amd64 r347403

2019-05-09 Thread Larry Rosenman

On 05/09/2019 5:19 pm, Trond Endrestøl wrote:

Host is Windows 7 x64 SP1.
CPU is Core i7 960.
Hypervisor is VirtualBox 6.0.6.
VM is using UEFI.
Kernel config is
https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head

Crash happens early during boot, right after launching the APs.

fault virtual address   = 0x0
[...]
KDB backtrace:
db_trace_self_wrapper() at
vpanic() at
panic() at
trap_fatal() at
trap_pfault() at
trap() at
calltrap() at
-- trap 0xc, rip = 0x8196d63a, rsp = 0x8198d730, rbp =
0x8198d790 ---
fbt_provide_module_function() at 0x8196d63a =
fbt_provide_module_function+0x7a/frame 0x8198d790
link_elf_each_function_nameval() at 0x80822ae5 =
link_elf_each_function_nameval+0x115/frame 0x8198d7e0
fbt_provide_module() at 0x8196c33e =
fbt_provide_module+0xde/frame 0x8198dc10
fbt_linker_file_cb() at 0x8196c242 =
fbt_linker_file_cb+0x12/frame 0x8198dc20
linker_file_foreach() at 0x807c47b7 =
linker_file_foreach+0x67/frame 0x8198dc60
mi_startup() at 0x80786de6 = mi_startup+0x216/frame 
0x8198dcb0

btext() at 0x8030da2c = btext+0x2c
Uptime: 1s

Previous BE is r346969 and works flawlessly.
No dumpdev is enabled to capture the details this early during boot.
Suggestions are welcome.


There is a patch:
From: ma...@freebsd.org (on my Crash loading dtraceall thread):


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


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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-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 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, , );
+   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,
 linke

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


Crash loading dtraceall

2019-05-08 Thread Larry Rosenman
f80114df9000,
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


signature.asc
Description: PGP signature


Re: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 11:34 am, Larry Rosenman wrote:

On 05/02/2019 11:10 am, Larry Rosenman wrote:

On 05/02/2019 10:58 am, Warner Losh wrote:

On Thu, May 2, 2019 at 9:54 AM Larry Rosenman  wrote:


On 05/02/2019 9:41 am, Larry Rosenman wrote:
> On 05/02/2019 9:24 am, Warner Losh wrote:
>> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman  wrote:
>>
>>> On 05/02/2019 8:29 am, Warner Losh wrote:
>>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman 
wrote:
>>> >
>>> >> Upgraded from r346487 to r347007, and when I reboot, I get a
mountroot
>>> >> prompt.  If I answer it with the same BootFS I booted from
>>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run.
>>> >>
>>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt
>>> >>
>>> >> What else do we need?
>>> >>
>>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions
>>> >> and that did *NOT* change anything.
>>> >>
>>> >> Ideas?
>>> >>
>>> >
>>> > BIOS or UEFI booting?
>>>
>>> UEFI boot.
>>>
>>
>> So no change to \efi\boot\bootx64.efi (or whatever you are booting?
>>
>> Can you get the output of 'show' in the boot loader?
>>
>> Also, is there a way you can try one or two of the versions in between
>> 346487 and 347007 to try to narrow the changes down a bit?
>>
>> Warner
>
> show output in 4 screenshots:
> https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/
>
> What's the easiest way to try some of the other revisions?  And which
> would
> you suggest?  (I'm set up for meta-mode).
working with Kyle Evans on IRC, and backing /boot/loader.efi to 
r346487

lets the system boot
normally.



OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set 
in

your successfully booted system with kenv?



2 things: r346675 still works, and vfs.root.mountfrom *IS* set.

r346879 does *NOT* work.  Stepping back to r346759

r346759 *WORKS*.  So it's r346879 that breaks it.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 11:10 am, Larry Rosenman wrote:

On 05/02/2019 10:58 am, Warner Losh wrote:

On Thu, May 2, 2019 at 9:54 AM Larry Rosenman  wrote:


On 05/02/2019 9:41 am, Larry Rosenman wrote:
> On 05/02/2019 9:24 am, Warner Losh wrote:
>> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman  wrote:
>>
>>> On 05/02/2019 8:29 am, Warner Losh wrote:
>>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman 
wrote:
>>> >
>>> >> Upgraded from r346487 to r347007, and when I reboot, I get a
mountroot
>>> >> prompt.  If I answer it with the same BootFS I booted from
>>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run.
>>> >>
>>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt
>>> >>
>>> >> What else do we need?
>>> >>
>>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions
>>> >> and that did *NOT* change anything.
>>> >>
>>> >> Ideas?
>>> >>
>>> >
>>> > BIOS or UEFI booting?
>>>
>>> UEFI boot.
>>>
>>
>> So no change to \efi\boot\bootx64.efi (or whatever you are booting?
>>
>> Can you get the output of 'show' in the boot loader?
>>
>> Also, is there a way you can try one or two of the versions in between
>> 346487 and 347007 to try to narrow the changes down a bit?
>>
>> Warner
>
> show output in 4 screenshots:
> https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/
>
> What's the easiest way to try some of the other revisions?  And which
> would
> you suggest?  (I'm set up for meta-mode).
working with Kyle Evans on IRC, and backing /boot/loader.efi to 
r346487

lets the system boot
normally.



OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set 
in

your successfully booted system with kenv?



2 things: r346675 still works, and vfs.root.mountfrom *IS* set.

r346879 does *NOT* work.  Stepping back to r346759


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 10:58 am, Warner Losh wrote:

On Thu, May 2, 2019 at 9:54 AM Larry Rosenman  wrote:


On 05/02/2019 9:41 am, Larry Rosenman wrote:
> On 05/02/2019 9:24 am, Warner Losh wrote:
>> On Thu, May 2, 2019 at 7:40 AM Larry Rosenman  wrote:
>>
>>> On 05/02/2019 8:29 am, Warner Losh wrote:
>>> > On Wed, May 1, 2019 at 10:04 PM Larry Rosenman 
wrote:
>>> >
>>> >> Upgraded from r346487 to r347007, and when I reboot, I get a
mountroot
>>> >> prompt.  If I answer it with the same BootFS I booted from
>>> >> (zfs:zroot/ROOT/r347007) it continues to boot, and run.
>>> >>
>>> >> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt
>>> >>
>>> >> What else do we need?
>>> >>
>>> >> I did upgrade the EFI partitions, and the freebsd-boot partitions
>>> >> and that did *NOT* change anything.
>>> >>
>>> >> Ideas?
>>> >>
>>> >
>>> > BIOS or UEFI booting?
>>>
>>> UEFI boot.
>>>
>>
>> So no change to \efi\boot\bootx64.efi (or whatever you are booting?
>>
>> Can you get the output of 'show' in the boot loader?
>>
>> Also, is there a way you can try one or two of the versions in between
>> 346487 and 347007 to try to narrow the changes down a bit?
>>
>> Warner
>
> show output in 4 screenshots:
> https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/
>
> What's the easiest way to try some of the other revisions?  And which
> would
> you suggest?  (I'm set up for meta-mode).
working with Kyle Evans on IRC, and backing /boot/loader.efi to 
r346487

lets the system boot
normally.



OK. I noticed vfs.root.mountfrom wasn't set. Can you see if it's set in
your successfully booted system with kenv?



2 things: r346675 still works, and vfs.root.mountfrom *IS* set.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 9:41 am, Larry Rosenman wrote:

On 05/02/2019 9:24 am, Warner Losh wrote:

On Thu, May 2, 2019 at 7:40 AM Larry Rosenman  wrote:


On 05/02/2019 8:29 am, Warner Losh wrote:
> On Wed, May 1, 2019 at 10:04 PM Larry Rosenman  wrote:
>
>> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot
>> prompt.  If I answer it with the same BootFS I booted from
>> (zfs:zroot/ROOT/r347007) it continues to boot, and run.
>>
>> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt
>>
>> What else do we need?
>>
>> I did upgrade the EFI partitions, and the freebsd-boot partitions
>> and that did *NOT* change anything.
>>
>> Ideas?
>>
>
> BIOS or UEFI booting?

UEFI boot.



So no change to \efi\boot\bootx64.efi (or whatever you are booting?

Can you get the output of 'show' in the boot loader?

Also, is there a way you can try one or two of the versions in between
346487 and 347007 to try to narrow the changes down a bit?

Warner


show output in 4 screenshots: 
https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/


What's the easiest way to try some of the other revisions?  And which 
would

you suggest?  (I'm set up for meta-mode).
working with Kyle Evans on IRC, and backing /boot/loader.efi to r346487 
lets the system boot

normally.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 9:24 am, Warner Losh wrote:

On Thu, May 2, 2019 at 7:40 AM Larry Rosenman  wrote:


On 05/02/2019 8:29 am, Warner Losh wrote:
> On Wed, May 1, 2019 at 10:04 PM Larry Rosenman  wrote:
>
>> Upgraded from r346487 to r347007, and when I reboot, I get a mountroot
>> prompt.  If I answer it with the same BootFS I booted from
>> (zfs:zroot/ROOT/r347007) it continues to boot, and run.
>>
>> Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt
>>
>> What else do we need?
>>
>> I did upgrade the EFI partitions, and the freebsd-boot partitions
>> and that did *NOT* change anything.
>>
>> Ideas?
>>
>
> BIOS or UEFI booting?

UEFI boot.



So no change to \efi\boot\bootx64.efi (or whatever you are booting?

Can you get the output of 'show' in the boot loader?

Also, is there a way you can try one or two of the versions in between
346487 and 347007 to try to narrow the changes down a bit?

Warner


show output in 4 screenshots: 
https://www.lerctr.org/~ler/FreeBSD/NO-BOOT/


What's the easiest way to try some of the other revisions?  And which 
would

you suggest?  (I'm set up for meta-mode).



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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: Mount Root fails: r347007

2019-05-02 Thread Larry Rosenman

On 05/02/2019 8:29 am, Warner Losh wrote:

On Wed, May 1, 2019 at 10:04 PM Larry Rosenman  wrote:


Upgraded from r346487 to r347007, and when I reboot, I get a mountroot
prompt.  If I answer it with the same BootFS I booted from
(zfs:zroot/ROOT/r347007) it continues to boot, and run.

Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt

What else do we need?

I did upgrade the EFI partitions, and the freebsd-boot partitions
and that did *NOT* change anything.

Ideas?



BIOS or UEFI booting?

Warner
___
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"

UEFI boot.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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"


Mount Root fails: r347007

2019-05-01 Thread Larry Rosenman
Upgraded from r346487 to r347007, and when I reboot, I get a mountroot
prompt.  If I answer it with the same BootFS I booted from 
(zfs:zroot/ROOT/r347007) it continues to boot, and run.

Dmesg: https://www.lerctr.org/~ler/Boot-NoRoot.txt

What else do we need?

I did upgrade the EFI partitions, and the freebsd-boot partitions
and that did *NOT* change anything. 

Ideas?



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: lsof hangs with latest 13.0-CURRENT snapshot

2019-04-09 Thread Larry Rosenman

On 04/09/2019 2:41 pm, Rodney W. Grimes wrote:

On Tue, 2019-04-09 at 12:20 -0700, Rodney W. Grimes wrote:
> > After upgrading from FreeBSD-13.0-CURRENT-amd64-20190328-r345620 to
> > FreeBSD-13.0-CURRENT-amd64-20190404-r345863, lsof (4.92 from
> > packages)
> > hangs.
> >
> > This is true for bare metal installs and virtual machine installs.
> >
> > How to recreate:
> >
> >   Install FreeBSD-13.0-CURRENT-amd64-20190404-r345863 snapshot.
> >
> >   as root: lsof /sbin/init
> >
> > By running command with -b option, this error is displayed:
> >
> > lsof: status error on /sbin/init: Resource temporarily unavailable
> >
> > The return code is 1.
> >
> > This probably requires adjustment to lsof, but only the FreeBSD
> > snapshot changed, so I'll start here.
>
> Where did you get your lsof binary from?
>
> lsof has internal knowledge of kernel data structures
> and must be compiled to match the running system.
>
>
> > Thanks.
> > David Boyd.


lsof was installed via pkg install from pkg.freebsd.org.


That does not work well on ^head or for that mater any snapshot,
as I said, lsof has internal knowledge of kernel data structures
and must match the running kernel for it to work.

It should be complaining about a version mismatch, but perhaps
it was compiled recently enough that these are matching, but
there is still a datastruct that changed.

As the lsof maintainer, I heartily agree here
Compile it against your system, and if it still hangs, make me
a bugzilla ticket with the details.

Thanks!

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


kqueue send over unix socket?

2019-03-12 Thread Larry Rosenman

I'm working with Aki Tuomi of Dovecot and he asks:

I tried to ask if you could ask from some Kernel hacker why I cannot 
send kqueue() fd over unix socket, I get "Operation not supported".


Can anyone help me?



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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"


Use after Free panic: ZFS?

2019-01-29 Thread Larry Rosenman

I've seen a couple of these...
⌂70% [l...@borg.lerctr.org:/var/crash] $ uname -aKU
FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r343437 
LER-MINIMAL  amd64 139 139

⌂66% [l...@borg.lerctr.org:/var/crash] $

Ideas?  vmcore/symbols available.

borg.lerctr.org dumped core - see /var/crash/vmcore.7

Tue Jan 29 04:00:46 CST 2019

FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r343437 
LER-MINIMAL  amd64


panic: Memory modified after free 0xf807019ca980(32) val=0 @ 
0xf807019ca980


GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.

done.

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf807019ca980(32) val=0 @ 
0xf807019ca980


cpuid = 5
time = 1548755136
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe00f750c880

vpanic() at vpanic+0x1b4/frame 0xfe00f750c8e0
panic() at panic+0x43/frame 0xfe00f750c940
trash_ctor() at trash_ctor+0x4c/frame 0xfe00f750c950
uma_zalloc_arg() at uma_zalloc_arg+0x9df/frame 0xfe00f750c9e0
uma_zfree_arg() at uma_zfree_arg+0x46a/frame 0xfe00f750ca40
arc_buf_destroy_impl() at arc_buf_destroy_impl+0x133/frame 
0xfe00f750ca80

arc_buf_destroy() at arc_buf_destroy+0x17a/frame 0xfe00f750cab0
dbuf_destroy() at dbuf_destroy+0x87/frame 0xfe00f750cb10
dbuf_evict_one() at dbuf_evict_one+0x187/frame 0xfe00f750cb40
dbuf_evict_thread() at dbuf_evict_thread+0x185/frame 0xfe00f750cbb0
fork_exit() at fork_exit+0x84/frame 0xfe00f750cbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00f750cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 3d16h49m14s
Dumping 22587 out of 131028 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" 
(OFFSETOF_CURTHREAD));

(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:371
#2  0x80491760 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:451
#3  0x80491bc0 in vpanic (fmt=, 
ap=0xfe00f750c920)

at /usr/src/sys/kern/kern_shutdown.c:877
#4  0x80491913 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:804
#5  0x8071255c in trash_ctor (mem=, 
size=,

arg=, flags=)
at /usr/src/sys/vm/uma_dbg.c:82
#6  0x8070cf4f in uma_zalloc_arg (zone=0xf8203ffdc000,
udata=0x108, flags=1) at /usr/src/sys/vm/uma_core.c:2418
#7  0x8070d69a in bucket_alloc (zone=,
udata=, flags=)
at /usr/src/sys/vm/uma_core.c:433
#8  uma_zfree_arg (zone=0xf801059a, item=,
udata=0xf81042431940) at /usr/src/sys/vm/uma_core.c:3153
#9  0x812f8c13 in arc_free_data_buf (hdr=,
buf=0xfe025fe1e000, size=8192, tag=)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:5248

#10 arc_buf_destroy_impl (buf=0xf8190202ef00)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3270

#11 0x812f859a in arc_buf_destroy (buf=0xf8190202ef00,
tag=0xf80aea618840)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:3687

#12 0x8130d3d7 in dbuf_destroy (db=0xf80aea618840)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:2328

#13 0x81313bb7 in dbuf_evict_one ()
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:717

#14 0x8130b1d5 in dbuf_evict_thread (unused=)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:757

#15 0x80458a94 in fork_exit (
callout=0xffff8130b050 , arg=0x0,
frame=0xfe00f750cc00) at /usr/src/sys/kern/kern_fork.c:1055
#16 
(kgdb)



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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"


udp6: Page fault panics

2018-09-15 Thread Larry Rosenman
I've got 2 of these:

Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address   = 0x7c
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80631428
stack pointer   = 0x28:0xfe00ca17c440
frame pointer   = 0x28:0xfe00ca17c480
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 = 1225 (isc-worker0003)
trap number = 12
panic: page fault
cpuid = 4
time = 1537050918
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00ca17c0f0
vpanic() at vpanic+0x1a3/frame 0xfe00ca17c150
panic() at panic+0x43/frame 0xfe00ca17c1b0
trap_fatal() at trap_fatal+0x35f/frame 0xfe00ca17c200
trap_pfault() at trap_pfault+0x49/frame 0xfe00ca17c260
trap() at trap+0x2ba/frame 0xfe00ca17c370
calltrap() at calltrap+0x8/frame 0xfe00ca17c370
--- trap 0xc, rip = 0x80631428, rsp = 0xfe00ca17c440, rbp = 
0xfe00ca17c480 ---
selectroute() at selectroute+0x198/frame 0xfe00ca17c480
in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfe00ca17c4a0
ip6_output() at ip6_output+0xfd7/frame 0xfe00ca17c710
udp6_send() at udp6_send+0x720/frame 0xfe00ca17c8d0
sosend_dgram() at sosend_dgram+0x346/frame 0xfe00ca17c930
kern_sendit() at kern_sendit+0x201/frame 0xfe00ca17c9d0
sendit() at sendit+0x19e/frame 0xfe00ca17ca20
sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe00ca17ca80
amd64_syscall() at amd64_syscall+0x272/frame 0xfe00ca17cbb0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00ca17cbb0
--- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x800be5a9a, rsp = 
0x7fffdf9fa468, rbp = 0x7fffdf9fa4a0 --
-
Uptime: 35s


Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0x98
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80636b2b
stack pointer   = 0x28:0xfe00c9d864b0
frame pointer   = 0x28:0xfe00c9d86710
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 = 2274 (isc-worker0005)
trap number = 12
panic: page fault
cpuid = 6
time = 1537053032
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c9d86160
vpanic() at vpanic+0x1a3/frame 0xfe00c9d861c0
panic() at panic+0x43/frame 0xfe00c9d86220
trap_fatal() at trap_fatal+0x35f/frame 0xfe00c9d86270
trap_pfault() at trap_pfault+0x49/frame 0xfe00c9d862d0
trap() at trap+0x2ba/frame 0xfe00c9d863e0
calltrap() at calltrap+0x8/frame 0xfe00c9d863e0
--- trap 0xc, rip = 0x80636b2b, rsp = 0xfe00c9d864b0, rbp = 
0xfe00c9d86710 ---
ip6_output() at ip6_output+0xeeb/frame 0xfe00c9d86710
udp6_send() at udp6_send+0x720/frame 0xfe00c9d868d0
sosend_dgram() at sosend_dgram+0x346/frame 0xfe00c9d86930
kern_sendit() at kern_sendit+0x201/frame 0xfe00c9d869d0
sendit() at sendit+0x19e/frame 0xfe00c9d86a20
sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe00c9d86a80
amd64_syscall() at amd64_syscall+0x272/frame 0xfe00c9d86bb0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00c9d86bb0
--- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x800be5a9a, rsp = 
0x7fffdf5f8468, rbp = 0x7fffdf5f84a0 --
-
Uptime: 33m21s

both on r338696.

Ideas?

I *DO* have cores, and can give access.

This is one of my nameservers.




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


signature.asc
Description: PGP signature


Re: drm / drm2 removal in 12

2018-08-26 Thread Larry Rosenman
On Mon, Aug 27, 2018 at 06:21:57AM +0800, blubee blubeeme wrote:
> 
> You seem to miss the point where the you avoid breaking the system for any
> users not on the bleeding edge.
> 
> You technically adept guys can keep on hacking away, jumping through hoops
> and building your stuff as you see fit.
> Nobody will come take your steal your code away in the night. Feel free to
> keep on working on it, until implementing it
> doesn't break "old users" do the engineering work and improve your
> implementation.
> 
> There are so many seemingly dead code projects around this linuxkpi stuff
> that you guys just pump out code and abandon
> inconsistent lack of documentation, lack of testing, it's just a huge mess.
> 
> Work on cleaning all that stuff up and bring something sensible to the
> table, you cannot put onus on the core team to maintain
> that mess going forward because you're not capable of doing it yourselves.

If you don't like breakage, don't run HEAD/-CURRENT.  If it's not out in
HEAD/-CURRENT, we (the project, speaking as a ports committer) can't
move forward.  


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


signature.asc
Description: PGP signature


Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
On Sun, Aug 19, 2018 at 05:58:43PM +0100, John Baldwin wrote:
> On 8/19/18 5:28 PM, Kyle Evans wrote:
> > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh  wrote:
> >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman  wrote:
> >>
> >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote:
> >>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman  wrote:
> >>>>
> >>>>> With today's change to LUA as the loader, I seem to have an issue with
> >>>>> bhyhve:
> >>>>>
> >>>>> Consoles: userboot
> >>>>>
> >>>>> FreeBSD/amd64 User boot, Revision 1.1
> >>>>> (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org)
> >>>>> Startup error in /boot/lua/loader.lua:
> >>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> >>>>>
> >>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970
> >>>>> syms=[0x8+0x14cf28+0x8+0x163e57]
> >>>>> Hit [Enter] to boot immediately, or any other key for command prompt.
> >>>>> Booting [/boot/kernel/kernel]...
> >>>>>
> >>>>> These VM's have been running for MONTHS.
> >>>>>
> >>>>> Ideas?
> >>>>>
> >>>>
> >>>> There's no boot/lua/loader.lua.
> >>>>
> >>>> You can either fix that, or you can recompile with
> >>>> LOADER_DEFAULT_INTERP=4th for the moment.
> >>> actually on the host there is:
> >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/
> >>> total 131
> >>> -r--r--r--  1 root  wheel   3895 Aug 19 09:46 cli.lua
> >>> -r--r--r--  1 root  wheel   3204 Aug 19 09:46 color.lua
> >>> -r--r--r--  1 root  wheel  14024 Aug 19 09:46 config.lua
> >>> -r--r--r--  1 root  wheel  10302 Aug 19 09:46 core.lua
> >>> -r--r--r--  1 root  wheel   9986 Aug 19 09:46 drawer.lua
> >>> -r--r--r--  1 root  wheel   3324 Aug 19 09:46 hook.lua
> >>> -r--r--r--  1 root  wheel   2543 Aug 19 09:46 loader.lua
> >>> -r--r--r--  1 root  wheel   2431 Aug 19 09:46 logo-beastie.lua
> >>> -r--r--r--  1 root  wheel   2203 Aug 19 09:46 logo-beastiebw.lua
> >>> -r--r--r--  1 root  wheel   1958 Aug 19 09:46 logo-fbsdbw.lua
> >>> -r--r--r--  1 root  wheel   2399 Aug 19 09:46 logo-orb.lua
> >>> -r--r--r--  1 root  wheel   2119 Aug 19 09:46 logo-orbbw.lua
> >>> -r--r--r--  1 root  wheel  12010 Aug 19 09:46 menu.lua
> >>> -r--r--r--  1 root  wheel   3941 Aug 19 09:46 password.lua
> >>> -r--r--r--  1 root  wheel   2381 Aug 19 09:46 screen.lua
> >>> borg.lerctr.org /home/ler $
> >>>
> >>> This is when booting the vm, and it's not on the vm's disk.
> >>>
> >>> So the bhyveload behavior *CHANGED*.
> >>>
> >>> POLA?
> >>>
> >>
> >> Unlikely, but a couple of questions. Have you always used the LUA loader,
> >> or is this a change with the recent default switch?
> >>
> >> And to be clear, you expect the host's file to be used for this, not the VM
> >> filesystem?
> >>
> > 
> > (CC'ing jhb@ and tychon@, who might have better insight)
> > 
> > If we can swing it, I think the best model here should have always
> > been that userboot uses the host's scripts but the guest's
> > loader.conf. The current model doesn't tolerate any mismatch between
> > host and guest and looks unsustainable.
> 
> Err, normally guests read things out of the a guest disk image (think most
> VMs like VirtualBox, etc.).  userboot.so is looking in the guest's disk image.
> Now, userboot isn't memory limited like the BIOS boot, so if it's
> possible to have userboot just include both lua and forth perhaps with
> some auto-detection based on what is in /boot/loader.rc to determine
> which interpreter to use, that is really the best path forward.

That won't help (looking at /boot/loader.rc) as my lua updated system
still has:

borg.lerctr.org /home/ler $ more /boot/loader.rc
\ Loader.rc
\ $FreeBSD: head/stand/i386/loader/loader.rc 331326 2018-03-21 22:01:51Z kevans 
$
\
\ Includes additional commands
include /boot/loader.4th
include /boot/efi.4th
try-include /boot/loader.rc.local

\ Reads and processes loader.conf variables
initialize

maybe-efi-resizecons

\ Tests for password -- executes autoboot first if a password was defined
check-password

\ Load in the boot menu
include /boot/beastie.4th

\ Start the boot menu
beastie-start
borg.lerctr.org /home/ler $

so it still looks forth'ish, but it's using lua.


> 
> -- 
> John Baldwin
> ___
> 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"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote:
> > filesystem?
> >
> 
> (CC'ing jhb@ and tychon@, who might have better insight)
> 
> If we can swing it, I think the best model here should have always
> been that userboot uses the host's scripts but the guest's
> loader.conf. The current model doesn't tolerate any mismatch between
> host and guest and looks unsustainable.

Yeah, I have a FreeBSD-10, and a HardendBSD-12 VM, and BOTH failed until
I loaded the old /boot/userboot.so to my host. 

We really need to tolerate this condition, and NOT surprise the user.
> 
> Thanks,
> 
> Kyle Evans
> ___
> 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"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
On Sun, Aug 19, 2018 at 11:54:51AM -0400, Joe Maloney wrote:
> I ran into this as well months ago.  To workaround it I extracted
> userboot.so for the VM's, and launched bhyve with the alternate
> userboot.so.  You can use a flag as described in the manpage to start
> userboot.so from an alternate location.
> 
> https://www.freebsd.org/cgi/man.cgi?query=bhyveload=8
> 
> Also support was recently added for vm-bhyve to specify alternate
> userboot.so location for one that is compatible with 4th.  You just need to
> extract that somewhere onto the host, and specify it to load when starting
> the VM.
> 
> https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample
> 
> Alternatively you could just use UEFI, or UEFI-CSM firmware.
Ok, so pulling /boot/userboot.so from my non-upgraded 12 system and
putting it in /boot/userboot-4th.so on the host allows the VM's to boot
after changing the config files to point bhyveload_loader to it (yes,
I'm using vm-bhyve). 

This default change is a POLA violation for bhyve/vm-bhyve users. 

[snip]

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


signature.asc
Description: PGP signature


Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
On Sun, Aug 19, 2018 at 09:42:05AM -0600, Warner Losh wrote:
> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman  wrote:
> 
> > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote:
> > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman  wrote:
> > >
> > > > With today's change to LUA as the loader, I seem to have an issue with
> > > > bhyhve:
> > > >
> > > > Consoles: userboot
> > > >
> > > > FreeBSD/amd64 User boot, Revision 1.1
> > > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org)
> > > > Startup error in /boot/lua/loader.lua:
> > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> > > >
> > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970
> > > > syms=[0x8+0x14cf28+0x8+0x163e57]
> > > > Hit [Enter] to boot immediately, or any other key for command prompt.
> > > > Booting [/boot/kernel/kernel]...
> > > >
> > > > These VM's have been running for MONTHS.
> > > >
> > > > Ideas?
> > > >
> > >
> > > There's no boot/lua/loader.lua.
> > >
> > > You can either fix that, or you can recompile with
> > > LOADER_DEFAULT_INTERP=4th for the moment.
> > actually on the host there is:
> > borg.lerctr.org /home/ler $ ls -l /boot/lua/
> > total 131
> > -r--r--r--  1 root  wheel   3895 Aug 19 09:46 cli.lua
> > -r--r--r--  1 root  wheel   3204 Aug 19 09:46 color.lua
> > -r--r--r--  1 root  wheel  14024 Aug 19 09:46 config.lua
> > -r--r--r--  1 root  wheel  10302 Aug 19 09:46 core.lua
> > -r--r--r--  1 root  wheel   9986 Aug 19 09:46 drawer.lua
> > -r--r--r--  1 root  wheel   3324 Aug 19 09:46 hook.lua
> > -r--r--r--  1 root  wheel   2543 Aug 19 09:46 loader.lua
> > -r--r--r--  1 root  wheel   2431 Aug 19 09:46 logo-beastie.lua
> > -r--r--r--  1 root  wheel   2203 Aug 19 09:46 logo-beastiebw.lua
> > -r--r--r--  1 root  wheel   1958 Aug 19 09:46 logo-fbsdbw.lua
> > -r--r--r--  1 root  wheel   2399 Aug 19 09:46 logo-orb.lua
> > -r--r--r--  1 root  wheel   2119 Aug 19 09:46 logo-orbbw.lua
> > -r--r--r--  1 root  wheel  12010 Aug 19 09:46 menu.lua
> > -r--r--r--  1 root  wheel   3941 Aug 19 09:46 password.lua
> > -r--r--r--  1 root  wheel   2381 Aug 19 09:46 screen.lua
> > borg.lerctr.org /home/ler $
> >
> > This is when booting the vm, and it's not on the vm's disk.
> >
> > So the bhyveload behavior *CHANGED*.
> >
> > POLA?
> >
> 
> Unlikely, but a couple of questions. Have you always used the LUA loader,
> or is this a change with the recent default switch?
I've *NEVER* used the lua loader until today's default change.
> 
> And to be clear, you expect the host's file to be used for this, not the VM
> filesystem?

No, but apparently /boot/userboot.so (from the host?) DOES expect the
VM's disk to have lua now. 


> 
> I'll look into this later today.

Thanks.
> 
> Warner
> ___
> 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"

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


signature.asc
Description: PGP signature


Re: LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote:
> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman  wrote:
> 
> > With today's change to LUA as the loader, I seem to have an issue with
> > bhyhve:
> >
> > Consoles: userboot
> >
> > FreeBSD/amd64 User boot, Revision 1.1
> > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org)
> > Startup error in /boot/lua/loader.lua:
> > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> >
> > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970
> > syms=[0x8+0x14cf28+0x8+0x163e57]
> > Hit [Enter] to boot immediately, or any other key for command prompt.
> > Booting [/boot/kernel/kernel]...
> >
> > These VM's have been running for MONTHS.
> >
> > Ideas?
> >
> 
> There's no boot/lua/loader.lua.
> 
> You can either fix that, or you can recompile with
> LOADER_DEFAULT_INTERP=4th for the moment.
actually on the host there is:
borg.lerctr.org /home/ler $ ls -l /boot/lua/
total 131
-r--r--r--  1 root  wheel   3895 Aug 19 09:46 cli.lua
-r--r--r--  1 root  wheel   3204 Aug 19 09:46 color.lua
-r--r--r--  1 root  wheel  14024 Aug 19 09:46 config.lua
-r--r--r--  1 root  wheel  10302 Aug 19 09:46 core.lua
-r--r--r--  1 root  wheel   9986 Aug 19 09:46 drawer.lua
-r--r--r--  1 root  wheel   3324 Aug 19 09:46 hook.lua
-r--r--r--  1 root  wheel   2543 Aug 19 09:46 loader.lua
-r--r--r--  1 root  wheel   2431 Aug 19 09:46 logo-beastie.lua
-r--r--r--  1 root  wheel   2203 Aug 19 09:46 logo-beastiebw.lua
-r--r--r--  1 root  wheel   1958 Aug 19 09:46 logo-fbsdbw.lua
-r--r--r--  1 root  wheel   2399 Aug 19 09:46 logo-orb.lua
-r--r--r--  1 root  wheel   2119 Aug 19 09:46 logo-orbbw.lua
-r--r--r--  1 root  wheel  12010 Aug 19 09:46 menu.lua
-r--r--r--  1 root  wheel   3941 Aug 19 09:46 password.lua
-r--r--r--  1 root  wheel   2381 Aug 19 09:46 screen.lua
borg.lerctr.org /home/ler $

This is when booting the vm, and it's not on the vm's disk.

So the bhyveload behavior *CHANGED*.

POLA?


> 
> Warner
> ___
> 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"

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


signature.asc
Description: PGP signature


LUA loader: bhyve now doesn't?

2018-08-19 Thread Larry Rosenman
With today's change to LUA as the loader, I seem to have an issue with
bhyhve:

Consoles: userboot

FreeBSD/amd64 User boot, Revision 1.1
(Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org)
Startup error in /boot/lua/loader.lua:
LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

/boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 
syms=[0x8+0x14cf28+0x8+0x163e57]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...

These VM's have been running for MONTHS.

Ideas?




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


signature.asc
Description: PGP signature


Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]

2018-08-16 Thread Larry Rosenman
On Thu, Aug 16, 2018 at 12:43:42PM -0400, Charlie Li wrote:
> On 16/08/2018 12:26, Brad Davis wrote:
> > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote:
> >> This was caused by r337852, but I didn't investigated further.
> >>
> >> The problem is that we have a source file called 'moduli.c' in
> >> crypto/openssh/ while the build target was moduli, and bmake seen
> >> 'moduli' in source tree as older than moduli.c, and decided to rebuild
> >> it from source, while the two files are unrelated.
> > 
> > Hi Xin,
> > 
> > I don't see how that could be the case as I didn't move the file around, I 
> > just moved how it gets installed.
> > 
> > I have done many many builds with this change in and haven't seen this 
> > problem..
> > 
> I've found this one intermittent at best. I'll run a buildworld on
> anything newer than r337852, get the linker error, update to even the
> next newer revision that changes completely unrelated files, build
> succeeds. Case in point, r337835 to r337863 failed, but r337863 to
> r337865 succeeded.
> 
> This is all with META_MODE, so could be a bug with that.
I've seen the same thing with meta-mode.  A svn up after the failure
restores the missing moduli file, and a re-run will succeed.

borg.lerctr.org /usr/src $ sudo svn up
Updating '.':
Restored 'crypto/openssh/moduli'
At revision 337914.
borg.lerctr.org /usr/src $


> 
> -- 
> Charlie Li
> Can't think of a witty .sigline today…
> 
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
> 




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: Crash in udp6_input on -HEAD

2018-07-04 Thread Larry Rosenman
On Wed, Jul 04, 2018 at 06:57:19PM +0200, Hans Petter Selasky wrote:
> On 07/04/18 18:51, Larry Rosenman wrote:
> > borg.lerctr.org dumped core - see /var/crash/vmcore.0
> 
> > 
> > Ideas?
> > 
> https://svnweb.freebsd.org/changeset/base/335958

Thanks!  That fixes it for me.
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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 in udp6_input on -HEAD

2018-07-04 Thread Larry Rosenman
borg.lerctr.org dumped core - see /var/crash/vmcore.0

Wed Jul  4 11:37:29 CDT 2018

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #46 r335957: Wed Jul  
4 11:08:13 CDT 2018 
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64

panic: page fault

GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
<118>Starting cupsd.


Fatal trap 12: page fault while in kernel mode
cpuid = 17; apic id = 05
fault virtual address   = 0x60
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80e0f61f
stack pointer   = 0x28:0xfe4288a0
frame pointer   = 0x28:0xfe4289b0
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 = 12 (swi1: netisr 0)
trap number = 12
panic: page fault
cpuid = 17
time = 1530721146
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe428550
vpanic() at vpanic+0x1a3/frame 0xfe4285b0
panic() at panic+0x43/frame 0xfe428610
trap_fatal() at trap_fatal+0x35f/frame 0xfe428660
trap_pfault() at trap_pfault+0x49/frame 0xfe4286c0
trap() at trap+0x2ba/frame 0xfe4287d0
calltrap() at calltrap+0x8/frame 0xfe4287d0
--- trap 0xc, rip = 0x80e0f61f, rsp = 0xfe4288a0, rbp = 
0xfe4289b0 ---
udp6_input() at udp6_input+0xbdf/frame 0xfe4289b0
ip6_input() at ip6_input+0xdd8/frame 0xfe428aa0
swi_net() at swi_net+0x1b9/frame 0xfe428b20
intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 
0xfe428b60
ithread_loop() at ithread_loop+0xb7/frame 0xfe428bb0
fork_exit() at fork_exit+0x84/frame 0xfe428bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe428bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 1m3s
Dumping 6608 out of 130994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:231
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x80b909b2 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:446
#3  0x80b90f93 in vpanic (fmt=, ap=0xfe4285f0)
at /usr/src/sys/kern/kern_shutdown.c:863
#4  0x80b90fe3 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:790
#5  0x8107291f in trap_fatal (frame=0xfe4287e0, eva=96)
at /usr/src/sys/amd64/amd64/trap.c:892
#6  0x81072979 in trap_pfault (frame=0xfe4287e0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:728
#7  0x81071f9a in trap (frame=0xfe4287e0)
at /usr/src/sys/amd64/amd64/trap.c:427
#8  
#9  udp6_input (mp=, offp=, 
proto=) at /usr/src/sys/netinet6/udp6_usrreq.c:424
#10 0x80df0c18 in ip6_input (m=0xf80237299400)
at /usr/src/sys/netinet6/ip6_input.c:962
#11 0x80cb6919 in netisr_process_workstream_proto (
nwsp=, proto=)
at /usr/src/sys/net/netisr.c:901
#12 swi_net (arg=) at /usr/src/sys/net/netisr.c:948
#13 0x80b52289 in intr_event_execute_handlers (p=, 
ie=0xf8012088e500) at /usr/src/sys/kern/kern_intr.c:1013
#14 0x80b529c7 in ithread_execute_handlers (ie=, 
p=) at /usr/src/sys/kern/kern_intr.c:1026
#15 ithread_loop (arg=0xf8012088e100)
at /usr/src/sys/kern/kern_intr.c:1106
#16 0x80b4f704 in fork_exit (
callout=0x80b52910 , arg=0xf8012088e100, 
frame=0xfe428c00) at /usr/src/sys/kern/kern_fork.c:1057
#17 
(kgdb) 


vmcore *IS* available, as is a 2nd one.

This is after an upgrade from 
FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #45 r335610: Sun Jun 
24 17:12:56 CDT 2018     
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64 1200069 
1200071
to r33

Re: DNSSEC/Log Spam for partially DNSSEC domain

2018-06-29 Thread Larry Rosenman
On Fri, Jun 29, 2018 at 07:33:02PM -0700, Michael Mitchell wrote:
> /etc/syslog.conf maybe
> 
> mdm - from a phone
> 
That won't help, as I don't want to suppress ALL of the nastygrams.

I'm looking for more selectivity from this in libc.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: DNSSEC/Log Spam for partially DNSSEC domain

2018-06-29 Thread Larry Rosenman
On Fri, Jun 29, 2018 at 08:29:48PM -0700, Michael Mitchell wrote:
> pick the right options for the daemon and info level?
Nope, it's just this message which is annoying.

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


DNSSEC/Log Spam for partially DNSSEC domain

2018-06-29 Thread Larry Rosenman
I'm running Exim, with DNSSEC enabled, and my zone (lerctr.org) is
DNSSEC signed, but my dyn.lerctr.org subdomain is NOT DNSSEC signed due
to HE.net don't support DNSSEC. 

I get a ton of:
Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for 
"borg.lerctr.org IN ", got type "RRSIG"
Jun 29 20:12:53 thebighonker exim[37649]: gethostby*.gethostanswer: asked for 
"borg.lerctr.org IN A", got type "RRSIG"

in my logs, which comes from libc:
/usr/src/lib/libc/net/getaddrinfo.c:
   2092 #ifdef DEBUG
   2093 if (type != T_KEY && type != T_SIG &&
   2094 type != ns_t_dname)
   2095 syslog(LOG_NOTICE|LOG_AUTH,
   2096"gethostby*.getanswer: asked for \"%s %s %s\", got type 
\"%s\"",
   2097qname, p_class(C_IN), 
p_type(qtype),
   2098p_type(type));
   2099 #endif

Is there an easy way to make this quieter?




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


signature.asc
Description: PGP signature


rack: m_copydata: negative offset panic

2018-06-09 Thread Larry Rosenman
Got the following panic. vmcore IS available:

borg.lerctr.org dumped core - see /var/crash/vmcore.0

Sat Jun  9 16:46:17 CDT 2018

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #35 r334894: Sat Jun  
9 15:53:46 CDT 2018 
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64

panic: m_copydata, negative off -1

GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
panic: m_copydata, negative off -1
cpuid = 20
time = 1528580395
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe344db496d0
vpanic() at vpanic+0x1a3/frame 0xfe344db49730
doadump() at doadump/frame 0xfe344db497b0
m_copydata() at m_copydata+0x111/frame 0xfe344db497f0
rack_output() at rack_output+0x31fd/frame 0xfe344db49a60
tcp_hpts_thread() at tcp_hpts_thread+0x6ab/frame 0xfe344db49b20
intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 
0xfe344db49b60
ithread_loop() at ithread_loop+0xb7/frame 0xfe344db49bb0
fork_exit() at fork_exit+0x84/frame 0xfe344db49bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe344db49bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 23m59s
Dumping 6766 out of 130994 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:231
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x80b844d2 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:446
#3  0x80b84ab3 in vpanic (fmt=, ap=0xfe344db49770)
at /usr/src/sys/kern/kern_shutdown.c:863
#4  0x80b84820 in kassert_panic (
fmt=0x8125ae7e "m_copydata, negative off %d")
at /usr/src/sys/kern/kern_shutdown.c:749
#5  0x80c107f1 in m_copydata (m=0xf801e3e5c400, off=-1, len=15,
cp=0xf801e3e686a4 
"\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336"...)
at /usr/src/sys/kern/uipc_mbuf.c:582
#6  0x839a739d in rack_output (tp=)
at /usr/src/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:7922
#7  0x80da568b in tcp_hptsi (hpts=, ctick=0x59f)
at /usr/src/sys/netinet/tcp_hpts.c:1615
#8  tcp_hpts_thread (ctx=)
at /usr/src/sys/netinet/tcp_hpts.c:1808
#9  0x80b46369 in intr_event_execute_handlers (p=,
ie=0xf80151f47d00) at /usr/src/sys/kern/kern_intr.c:1013
#10 0x80b46a57 in ithread_execute_handlers (ie=,
p=) at /usr/src/sys/kern/kern_intr.c:1026
#11 ithread_loop (arg=0xf80151f47900)
at /usr/src/sys/kern/kern_intr.c:1106
#12 0x80b43754 in fork_exit (
callout=0xffff80b469a0 , arg=0xf80151f47900,
frame=0xfe344db49c00) at /usr/src/sys/kern/kern_fork.c:1039
#13 
(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


signature.asc
Description: PGP signature


Re: Error build nvidia-driver with r334555

2018-06-03 Thread Larry Rosenman
sysutils/lsof fixed in r471495.

 

Thanks, Mateusz!

-- 

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

 

From: Mateusz Guzik 
Date: Sunday, June 3, 2018 at 8:20 AM
To: 
Cc: "freebsd-current@freebsd.org" , 
, Mateusz Guzik , Alexey Dokuchaev 
, 
Subject: Re: Error build nvidia-driver with r334555

 

On Sun, Jun 3, 2018 at 2:42 PM, Tomoaki AOKI  wrote:

This is caused by r334533 and/or r334534 (memset-related changes).
sysutils/lsof is also affected.

You should revert r334533 and r334534 temporarily until nvidia-driver
support this change.

CC'ing the revision author and maintainers of both ports.

 

 

Support in what sense? The error message clearly indicates a bug in the driver

(also trivially fixable). Is there a problem adding a patch to files/?

diff -ru src.orig/nvidia/nvidia_subr.c src/nvidia/nvidia_subr.c
--- src.orig/nvidia/nvidia_subr.c2018-06-03 13:19:56.49048 +
+++ src/nvidia/nvidia_subr.c2018-06-03 13:21:15.289344000 +
@@ -364,7 +364,7 @@
 }
 
 ci = args;
-memset(ci, 0, sizeof(ci));
+memset(ci, 0, sizeof(*ci));
 
 for (i = 0; i < NV_MAX_DEVICES; i++) {
 sc = devclass_get_softc(nvidia_devclass, i);

As for lsof:
--- dlsof.h.orig2018-06-03 13:16:14.712701000 +
+++ dlsof.h2018-06-03 13:17:15.042655000 +
@@ -489,6 +489,12 @@
 # endif/* FREEBSDV>=2020 */
 
 #undefbzero/* avoid _KERNEL conflict */
+#undefbcmp
+#undefbcopy
+#undefmemcmp
+#undefmemmove
+#undefmemcpy
+#undefmemset
 #include 

-- 

Mateusz Guzik 

___
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: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-04-03 Thread Larry Rosenman
Thanks for that hint.  I thought that arc_max was a tunable, but now knowing 
it's sysctl, that helps a lot.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 4/3/18, 8:54 PM, "Cy Schubert" <owner-freebsd-curr...@freebsd.org on behalf 
of cy.schub...@cschubert.com> wrote:

Try arbitrarily reducing arc_max through sysctl. ARC is immediately reduced 
and free memory increased however wired pages remains the same.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-----
From: Larry Rosenman
Sent: 03/04/2018 19:27
To: Cy Schubert; Bryan Drewery; Peter Jeremy; Jeff Roberson
Cc: FreeBSD current; Andriy Gapon
Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

When my full backups run (1st Sunday -> Monday of the month) the box 
becomes unusable after 5-10 hours of that backup with LOTS of SWAP usage
And ARC using 100+G. 

Is anyone looking into this?
    


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 4/3/18, 8:24 PM, "Cy Schubert" <owner-freebsd-curr...@freebsd.org on 
behalf of cy.schub...@cschubert.com> wrote:

+1

However under certain circumstances it will release some memory. To 
reproduce, when bsdtar unpacks some tarballs (when building certain ports) tar 
will use 12 GB or  more  forcing ARC to release memory.

BTW, I haven't stopped to grok whether the bsdtar issue is local to me 
or another problem yet.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Bryan Drewery
Sent: 23/03/2018 17:23
To: Peter Jeremy; Jeff Roberson
Cc: FreeBSD current; Andriy Gapon
Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

On 3/20/2018 12:07 AM, Peter Jeremy wrote:
> 
> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson 
<jrober...@jroberson.net> wrote:
>> Also, if you could try going back to r328953 or r326346 and let me 
know if 
>> the problem exists in either.  That would be very helpful.  If 
anyone is 
>> willing to debug this with me contact me directly and I will send 
some 
>> test patches or debugging info after you have done the above steps.
> 
> I ran into this on 11-stable and tracked it to r326619 (MFC of 
r325851).
> I initially got around the problem by reverting that commit but either
> it or something very similar is still present in 11-stable r331053.
> 
> I've seen it in my main server (32GB RAM) but haven't managed to 
reproduce
> it in smaller VBox guests - one difficulty I faced was artificially 
filling
> ARC.
> 

Looking at the ARC change you referred to from r325851
https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure
is completely broken. On my 78GB RAM system with ARC limited to 40GB and
doing a poudriere build of all LLVM and GCC packages at once in tmpfs I
can get swap up near 50GB and yet the ARC remains at 40GB through it
all.  It's always been slow to give up memory for package builds but it
really seems broken right now.

-- 
Regards,
Bryan Drewery

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



___
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: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-04-03 Thread Larry Rosenman
When my full backups run (1st Sunday -> Monday of the month) the box becomes 
unusable after 5-10 hours of that backup with LOTS of SWAP usage
And ARC using 100+G. 

Is anyone looking into this?



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 4/3/18, 8:24 PM, "Cy Schubert" <owner-freebsd-curr...@freebsd.org on behalf 
of cy.schub...@cschubert.com> wrote:

+1

However under certain circumstances it will release some memory. To 
reproduce, when bsdtar unpacks some tarballs (when building certain ports) tar 
will use 12 GB or  more  forcing ARC to release memory.

BTW, I haven't stopped to grok whether the bsdtar issue is local to me or 
another problem yet.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Bryan Drewery
Sent: 23/03/2018 17:23
To: Peter Jeremy; Jeff Roberson
Cc: FreeBSD current; Andriy Gapon
Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

On 3/20/2018 12:07 AM, Peter Jeremy wrote:
> 
> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson <jrober...@jroberson.net> 
wrote:
>> Also, if you could try going back to r328953 or r326346 and let me know 
if 
>> the problem exists in either.  That would be very helpful.  If anyone is 
>> willing to debug this with me contact me directly and I will send some 
>> test patches or debugging info after you have done the above steps.
> 
> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851).
> I initially got around the problem by reverting that commit but either
> it or something very similar is still present in 11-stable r331053.
> 
> I've seen it in my main server (32GB RAM) but haven't managed to reproduce
> it in smaller VBox guests - one difficulty I faced was artificially 
filling
> ARC.
> 

Looking at the ARC change you referred to from r325851
https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure
is completely broken. On my 78GB RAM system with ARC limited to 40GB and
doing a poudriere build of all LLVM and GCC packages at once in tmpfs I
can get swap up near 50GB and yet the ARC remains at 40GB through it
all.  It's always been slow to give up memory for package builds but it
really seems broken right now.

-- 
Regards,
Bryan Drewery

___
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: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-06 Thread Larry Rosenman
On Tue, Mar 06, 2018 at 10:16:36AM -0800, Rodney W. Grimes wrote:
> > On Tue, Mar 06, 2018 at 08:40:10AM -0800, Rodney W. Grimes wrote:
> > > > On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote:
> > > > 
> > > > > Upgraded to:
> > > > > 
> > > > > FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 
> > > > > r330385: Sun Mar  4 12:48:52 CST 2018 
> > > > > r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64
> > > > > +1200060 1200060
> > > > > 
> > > > > Yesterday, and I'm seeing really strange slowness, ARC use, and SWAP 
> > > > > use and swapping.
> > > > > 
> > > > > See http://www.lerctr.org/~ler/FreeBSD/Swapuse.png
> > > > 
> > > > I see these symptoms on stable/11. One of my servers has 32 GiB of 
> > > > RAM. After a reboot all is well. ARC starts to fill up, and I still 
> > > > have more than half of the memory available for user processes.
> > > > 
> > > > After running the periodic jobs at night, the amount of wired memory 
> > > > goes sky high. /etc/periodic/weekly/310.locate is a particular nasty 
> > > > one.
> > > 
> > > I would like to find out if this is the same person I have
> > > reporting this problem from another source, or if this is
> > > a confirmation of a bug I was helping someone else with.
> > > 
> > > Have you been in contact with Michael Dexter about this
> > > issue, or any other forum/mailing list/etc?  
> > Just IRC/Slack, with no response.
> > > 
> > > If not then we have at least 2 reports of this unbound
> > > wired memory growth, if so hopefully someone here can
> > > take you further in the debug than we have been able
> > > to get.
> > What can I provide?  The system is still in this state as the full backup 
> > is slow.
> 
> One place to look is to see if this is the recently fixed:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=88
> g_bio leak.
> 
> vmstat -z | egrep 'ITEM|g_bio|UMA'
> 
> would be a good first look
> 
borg.lerctr.org /home/ler $ vmstat -z | egrep 'ITEM|g_bio|UMA'
ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
UMA Kegs:   280,  0, 346,   5, 560,   0,   0
UMA Zones: 1928,  0, 363,   1, 577,   0,   0
UMA Slabs:  112,  0,25384098,  977762,102033225,   0,   0
UMA Hash:   256,  0,  59,  16, 105,   0,   0
g_bio:  384,  0,  33,1627,542482056,   0,   0
borg.lerctr.org /home/ler $
> > > > Limiting the ARC to, say, 16 GiB, has no effect of the high amount of 
> > > > wired memory. After a few more days, the kernel consumes virtually all 
> > > > memory, forcing processes in and out of the swap device.
> > > 
> > > Our experience as well.
> > > 
> > > ...
> > > 
> > > Thanks,
> > > Rod Grimes 
> > > rgri...@freebsd.org
> > Larry Rosenman http://www.lerctr.org/~ler
> 
> -- 
> Rod Grimes rgri...@freebsd.org

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-06 Thread Larry Rosenman
On Tue, Mar 06, 2018 at 08:40:10AM -0800, Rodney W. Grimes wrote:
> > On Mon, 5 Mar 2018 14:39-0600, Larry Rosenman wrote:
> > 
> > > Upgraded to:
> > > 
> > > FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385: 
> > > Sun Mar  4 12:48:52 CST 2018 
> > > r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64
> > > +1200060 1200060
> > > 
> > > Yesterday, and I'm seeing really strange slowness, ARC use, and SWAP use 
> > > and swapping.
> > > 
> > > See http://www.lerctr.org/~ler/FreeBSD/Swapuse.png
> > 
> > I see these symptoms on stable/11. One of my servers has 32 GiB of 
> > RAM. After a reboot all is well. ARC starts to fill up, and I still 
> > have more than half of the memory available for user processes.
> > 
> > After running the periodic jobs at night, the amount of wired memory 
> > goes sky high. /etc/periodic/weekly/310.locate is a particular nasty 
> > one.
> 
> I would like to find out if this is the same person I have
> reporting this problem from another source, or if this is
> a confirmation of a bug I was helping someone else with.
> 
> Have you been in contact with Michael Dexter about this
> issue, or any other forum/mailing list/etc?  
Just IRC/Slack, with no response.
> 
> If not then we have at least 2 reports of this unbound
> wired memory growth, if so hopefully someone here can
> take you further in the debug than we have been able
> to get.
What can I provide?  The system is still in this state as the full backup is 
slow.


> 
> > 
> > Limiting the ARC to, say, 16 GiB, has no effect of the high amount of 
> > wired memory. After a few more days, the kernel consumes virtually all 
> > memory, forcing processes in and out of the swap device.
> 
> Our experience as well.
> 
> ...
> 
> Thanks,
> -- 
> Rod Grimes rgri...@freebsd.org
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature


Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-05 Thread Larry Rosenman
Upgraded to:

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r330385: Sun Mar  
4 12:48:52 CST 2018 
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/VT-LER  amd64
+1200060 1200060

Yesterday, and I'm seeing really strange slowness, ARC use, and SWAP use and 
swapping.

See http://www.lerctr.org/~ler/FreeBSD/Swapuse.png

Ideas?



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.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"


Re: /usr/obj is 11GB huge on FreeBSD 12-current

2017-12-15 Thread Larry Rosenman
On 12/15/17, 1:28 PM, "owner-freebsd-curr...@freebsd.org" 
 wrote:


Wolfram Schneider writes:

>  I upgraded a machine from 11-stable to 12-current. The /usr/obj tree
>  is now 11GB huge:
>  
>  FreeBSD 12-current
>  $ du -hs /usr/obj
>   11G /usr/obj
>  
>  on FreeBSD 11-stable it was less the size:
>  $ du -hs /usr/obj
>  5.6G /usr/obj

Mine - also 12-current - reports 7.6G.
May we see your kernel config file, src.conf, and make.conf?


Respectfully,


Robert Huff


For the record:
borg.lerctr.org /usr/obj $ du -shA
 30G.
borg.lerctr.org /usr/obj $

borg.lerctr.org /usr/obj $ cat /etc/src.conf
WITH_CLANG_EXTRAS=yes
WITH_CLANG_FULL=yes
WITH_LLDB=yes
WITH_GCC=yes
WITH_GNUCXX=yes
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/var/cache/ccache
borg.lerctr.org /usr/obj $ cat /etc/make.conf
DEVELOPER=yes
SVN=/usr/local/bin/svn
SVN_UPDATE=yes
# DTRACE KERNEL, Stripped of unnecessary devices
#KERNCONF=BORG-DTRACE
KERNCONF=VT-LER

# USERLAND DTRACE
#STRIP=
#CFLAGS+=-fno-omit-frame-pointer
#WITH_CTF=1
#
#__EXIM__
LOG_FILE_PATH="syslog:${LOGDIR}/%slog"
LOGDIR=/var/log/exim
#

WITH_POSTGRES=yes

#WITH_APACHE2=yes
#CUPS is the default
WITH_CUPS=YES
CUPS_OVERWRITE_BASE=YES
WITHOUT_LPR=YES

WITH_JADETEX=yes
WITH_PKGNG=yes
#PORTS_MODULES+=emulators/virtualbox-ose-kmod
#PORTS_MODULES+=x11/nvidia-driver
#MALLOC_PRODUCTION=yes
DEFAULT_VERSIONS=pgsql=9.6 apache=2.4 php=7.0 linux=c7
#
borg.lerctr.org /usr/obj $

Doesn't bother me much.
(this might also be because of bdrewery@'s changes with meta-mode, and not 
clearing /usr/obj in a while, so there may be stale/old directories).



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


RACCT destroy Crash, regression: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027

2017-09-12 Thread Larry Rosenman
Can I get someone to look at this RACCT destroy panic?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027

It's been fixed before (see xref in the bug), but it's back.

Thanks!


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


signature.asc
Description: PGP signature


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027

2017-09-11 Thread Larry Rosenman
Can I get someone to look at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027

It's a bug that's been fixed before, but it's back.

Thanks!



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


signature.asc
Description: PGP signature


Re: -CURRENT: print/texinfo and apache24 issues at r320573

2017-07-03 Thread Larry Rosenman
On Mon, Jul 03, 2017 at 08:32:42PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > Since I upgraded my world/kernel to r320573 from r320339, I can't build 
> > print/texinfo nor
> > start my httpd. 
> > 
> > Ideas?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220304
> 
> has some pointer to perl built with PERL_MALLOC that causes the texinfo build 
> to fail ?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220447
> 
> has some more stuff with perl.
PERL_MALLOC not set for me, and rebuild didn't change anything?


> 
> -- 
> p...@opsec.eu+49 171 3101372 3 years to 
> go !
> ___
> 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"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


-CURRENT: print/texinfo and apache24 issues at r320573

2017-07-03 Thread Larry Rosenman

Since I upgraded my world/kernel to r320573 from r320339, I can't build 
print/texinfo nor
start my httpd. 

Ideas?


Larry Rosenman [12:18 PM] 
anyone else having issues building texinfo on -CURRENT? 
panic: bad free, ->next->prev=80509aaa0, header=80509aaa0, 
->prev->next=a5a5a5a5a5a50020 at ../tp/Texinfo/Parser.pm line 3907.
panic: bad free, ->next->prev=5a5a5a5a5a5a5a5a, header=80509a9b0, 
->prev->next=80509a9b0 during global destruction.
gmake[4]: *** [Makefile:1297: info-stnd.info] Error 25
gmake[4]: *** Waiting for unfinished jobs
Assertion failed: (header->next->prev == header), function Perl_safesysrealloc, 
file util.c, line 243.
Abort trap (core dumped)

[12:19] 
I also can’t get my httpd up it sigsegv’s in parsing it’s config

[12:19] 
driving me nuts today

[12:20] 
borg.lerctr.org 
/usr/local/poudriere/data/logs/bulk/live-host-ports/2017-07-02_12h16m20s/logs/errors
 $ uname -aKU
FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320573: Sun Jul  
2 10:50:05 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64 
1200037 1200037
borg.lerctr.org 
/usr/local/poudriere/data/logs/bulk/live-host-ports/2017-07-02_12h16m20s/logs/errors
 $

[12:21] 
borg.lerctr.org / $ gdb -c httpd.core /usr/local/sbin/httpd
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-portbld-freebsd12.0”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type “help”.
Type “apropos word” to search for commands related to “word”...
Reading symbols from /usr/local/sbin/httpd...(no debugging symbols 
found)...done.
[New LWP 101514]
Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT -t’.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000801d09b90 in strcmp () from /lib/libc.so.7
(gdb) bt
#0  0x000801d09b90 in strcmp () from /lib/libc.so.7
#1  0x00457d9a in process_resource_config_fnmatch ()
#2  0x00457d2f in process_resource_config_fnmatch ()
#3  0x00457d2f in process_resource_config_fnmatch ()
#4  0x00457d2f in process_resource_config_fnmatch ()
#5  0x00457d2f in process_resource_config_fnmatch ()
#6  0x00457d2f in process_resource_config_fnmatch ()
#7  0x00457a69 in ap_process_fnmatch_configs ()
#8  0x00448eb0 in include_config ()
#9  0x00459ac8 in invoke_cmd ()
#10 0x00456cda in ap_build_config_sub ()
#11 0x004571ab in ap_build_config ()
#12 0x004578d9 in ap_process_resource_config ()
#13 0x00458d81 in ap_read_config ()
#14 0x00430c8d in main ()
(gdb)
-- 
Larry Rosenman http://people.FreeBSD.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281


signature.asc
Description: PGP signature


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210315 <--- Back in -CURRENT?

2017-06-21 Thread Larry Rosenman
Greetings,
   I'm seeing what looks like the same panic that was fixed for:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210315 on -CURRENT when 
running 
poudriere runs. 

   I have a TEXTDUMP.

The info file:

Dump header from device: /dev/mfid0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 35840
  Blocksize: 512
  Dumptime: Wed Jun 21 11:25:38 2017
  Hostname: borg.lerctr.org
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 12.0-CURRENT #33 r320190: Wed Jun 21 10:22:24 CDT 2017
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER
  Panic String: destroying non-empty racct: 2990080 allocated for resource 4

  Dump Parity: 2020083251
  Bounds: 1
  Dump Status: good

I can *NOT* get a full dump due to not enough swap on a single partition. 

What can I supply to help get this fixed again?




-- 
Larry Rosenman http://people.FreeBSD.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281


signature.asc
Description: PGP signature


Update the Makefile for ioctl.c?

2017-06-21 Thread Larry Rosenman
Greetings,
   It looks like the Makefile for ioctl.c didn't get the memo on some
pieces being removed:

--- ioctl.c ---
egrep: dev/utopia/idtphy.h: No such file or directory
egrep: dev/utopia/suni.h: No such file or directory
egrep: dev/utopia/utopia.h: No such file or directory
egrep: dev/utopia/utopia_priv.h: No such file or directory
egrep: net/if_atm.h: No such file or directory
egrep: netgraph/atm/ng_atm.h: No such file or directory
egrep: netinet/if_atm.h: No such file or directory

I'm not sure what to fix here. :( 


-- 
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


destroying non-empty racct

2017-06-09 Thread Larry Rosenman
I know we had this a while back, and it was fixed, but it's back.


Dump header from device: /dev/mfid0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 105984
  Blocksize: 512
  Dumptime: Fri Jun  9 13:25:25 2017
  Hostname: borg.lerctr.org
  Magic: FreeBSD Text Dump
  Version String: FreeBSD 12.0-CURRENT #29 r319458: Thu Jun  1 16:15:44 CDT 2017
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER
  Panic String: destroying non-empty racct: 4124672 allocated for resource 4

  Dump Parity: 1629450792
  Bounds: 3
  Dump Status: good

I do NOT have a core due to insufficient swap (I do have a text dump).

Ideas?


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


adding -R to the skeleton file for the PAGER variable

2017-05-25 Thread Larry Rosenman
I ran into an "interesting" issue today using the devel/awscli
port. 

aws help

generates almost unreadable output using the "standard" shell .profile, etc. 

The reason is it uses $PAGER or $MANPAGER if it's present, and the skeleton
sets:

PAGER=more

which, using the .rst files that awscli has, just makes the output ESC 
sequences get printed and not acted upon. 

I'm wondering if there would be any objections to changing the "standard" 
skeleton PAGER environment to:

PAGER="more -R"

so the ESC sequences get passed through to the terminal unmolested and do the
right thing.

Comments?


-- 
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281


signature.asc
Description: PGP signature


Re: svn commit: r318757 - head

2017-05-24 Thread Larry Rosenman
On 5/24/17, 1:01 PM, "O. Hartmann" <ohartm...@walstatt.org> wrote:

Am Wed, 24 May 2017 19:40:46 +0200
"O. Hartmann" <ohartm...@walstatt.org> schrieb:

> Am Wed, 24 May 2017 12:28:51 -0500
> Larry Rosenman <l...@lerctr.org> schrieb:
> 
> > I fixed my issues by force-rebuilding perl and all installed p5-* 
ports. 
> > 
> >   
> 
> 
> This isn't possible in my case :-(
> 
> lang/perl rebuilds all right, but every p5-* ports fails with
> 
> [...]
> Checking if your kit is complete...
> ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
> 0xd200080, needed 0xdf00080) 
> *** Error code 1
> 
> I tried to rebuild also via portmaster -f, no success. Now, I growing 
bunch of ports
> showing up with this mysterious error.
> 
> To which port "ListUtil.c" might belong to?
> 
> Rebuilding autotools (which I suspected first) also fails ...
> 
> 

... it seems, as K. belousov mentioned prior regarding different ABI, all 
p5-* ports need
to be deleted by force ... They rebuild properly afterwards.

Which is essentially what I did re: Poudriere (poudriere bulk –C –j  -p 
 -f )

 


___
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: svn commit: r318757 - head

2017-05-24 Thread Larry Rosenman


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 12:40 PM, "O. Hartmann" <ohartm...@walstatt.org> wrote:

Am Wed, 24 May 2017 12:28:51 -0500
    Larry Rosenman <l...@lerctr.org> schrieb:

> I fixed my issues by force-rebuilding perl and all installed p5-* ports. 
> 
> 


This isn't possible in my case :-(

lang/perl rebuilds all right, but every p5-* ports fails with

[...]
Checking if your kit is complete...
ListUtil.c: loadable library and perl binaries are mismatched (got 
handshake key
0xd200080, needed 0xdf00080) 
*** Error code 1

I tried to rebuild also via portmaster -f, no success. Now, I growing bunch 
of ports
showing up with this mysterious error.

To which port "ListUtil.c" might belong to?

Rebuilding autotools (which I suspected first) also fails ...


I rebuilt all in Poudriere and it was fine.




___
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: svn commit: r318757 - head

2017-05-24 Thread Larry Rosenman
I fixed my issues by force-rebuilding perl and all installed p5-* ports. 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 


___
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: svn commit: r318757 - head

2017-05-24 Thread Larry Rosenman
The initial failure was NOT, except that the PostgreSQL build builds a PL/Perl 
interpreter that MIGHT
Be considered that.

It was unexpected.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 8:33 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:

On Wed, May 24, 2017 at 08:06:34AM -0500, Larry Rosenman wrote:
> The initial failure:
> 
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42
> 
> I then recompiled perl, and got:
> borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
> Socket.c: loadable library and perl binaries are mismatched (got 
handshake key 0xd200080, needed 0xdf00080)
> borg.lerctr.org /home/pgbuildfarm/bin/latest $
> 
> force rebuilding and installing perl and all p5-* ports fixed that. 
From what I understand in reading some perl bugs and perl source, perl
performs some validation of the structures shared between the perl
interpreter and XS libraries loaded into it. So I am almost sure that
you have perl itself and some module built against different src/ bases.

Is it true ?  If yes, then this is user error.  You are trying to mix
two binaries built against incompatible ABI.

> 
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>  
>  
> 
> On 5/24/17, 4:05 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:
> 
> On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> > My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> > lang/perl5.24
> > and all my p5-* ports. 
> So what was the symptoms and the error, exactly ?
> 
> A lot of efforts were spent to ensure that _consistent_ set of old 
binaries
> and libraries would run without issues on the new system.  I mean that
> if you have binaries and libraries built on pre-ino64 system, which do
> not reference any libraries built on post ino64, except system 
libraries
> (like libc/libthr etc), everything should work.  This feature was the
> main cause of long delay finishing ino64.
> 
> > 
> > emulators/qemu-user-static also won???t compile (sbruno@ is on this 
one).
> This is a separate issue.
> 
> > 
> > Poudriere did *NOT* force a fuill rebuild even though 
freebsd-version *WAS* bumped. 
> > 
    > > Is there a hazard for others here?
> > 
> > Or more info needed in /usr/{src,ports}/UPDATING?
> > 
> > 
> > -- 
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> >   
> > 
> > 
> > 
> 
> 



___
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: svn commit: r318757 - head

2017-05-24 Thread Larry Rosenman
The initial failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42

I then recompiled perl, and got:
borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && 
./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf
Socket.c: loadable library and perl binaries are mismatched (got handshake key 
0xd200080, needed 0xdf00080)
borg.lerctr.org /home/pgbuildfarm/bin/latest $

force rebuilding and installing perl and all p5-* ports fixed that. 



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/24/17, 4:05 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote:

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> lang/perl5.24
> and all my p5-* ports. 
So what was the symptoms and the error, exactly ?

A lot of efforts were spent to ensure that _consistent_ set of old binaries
and libraries would run without issues on the new system.  I mean that
if you have binaries and libraries built on pre-ino64 system, which do
not reference any libraries built on post ino64, except system libraries
(like libc/libthr etc), everything should work.  This feature was the
main cause of long delay finishing ino64.

> 
> emulators/qemu-user-static also won???t compile (sbruno@ is on this one).
This is a separate issue.

> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
*WAS* bumped. 
> 
> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>   
> 
> 
> 



___
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: svn commit: r318757 - head

2017-05-23 Thread Larry Rosenman
borg.lerctr.org /home/ler $ sudo poudriere jail -l
JAILNAME   VERSION  ARCH  METHOD   TIMESTAMP   PATH
p103amd64  10.3-RELEASE-p18 amd64 http 2017-04-23 08:39:24 
/usr/local/poudriere/jails/p103amd64
p103i386   10.3-RELEASE-p18 i386  http 2017-04-23 08:40:44 
/usr/local/poudriere/jails/p103i386
p110amd64  11.0-RELEASE-p10 amd64 http 2017-05-15 14:54:58 
/usr/local/poudriere/jails/p110amd64
p110i386   11.0-RELEASE-p9  i386  http 2017-04-23 08:41:48 
/usr/local/poudriere/jails/p110i386
live   12.0-CURRENT amd64 src=/usr/src 2017-05-23 13:39:40 
/usr/local/poudriere/jails/live
pHEADamd64 12.0-CURRENT amd64 src=/usr/src 2017-04-24 17:15:13 
/usr/local/poudriere/jails/pHEADamd64
p120armv6  12.0-CURRENT r317340 arm.armv6 svn+https2017-04-23 10:07:40 
/usr/local/poudriere/jails/p110borg.lerctr.org 
/usr/local/etc/poudriere.d/jails/live $ cat version
12.0-CURRENT
borg.lerctr.org /usr/local/etc/poudriere.d/jails/live $armv6
borg.lerctr.org /home/ler $


borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $ cat 
.jailversion
12.0-CURRENT
borg.lerctr.org /usr/local/poudriere/data/packages/live-host-ports $



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 5/23/17, 6:08 PM, "Bryan Drewery" <bdrew...@freebsd.org> wrote:

On 5/23/2017 2:46 PM, Larry Rosenman wrote:
> My PostgreSQL buildfarm animal BROKE with this change until I force 
rebuilt
> lang/perl5.24
> and all my p5-* ports. 
> 
> emulators/qemu-user-static also won’t compile (sbruno@ is on this one).
> 
> Poudriere did *NOT* force a fuill rebuild even though freebsd-version 
*WAS* bumped. 
> 

It should have.
What version are you using?
Can you show output of 'poudriere jail -l' please?
And show /usr/local/etc/poudriere.d/jails/JAILNAME/version
And show the .jailversion output from your PACKAGES directory.

> Is there a hazard for others here?
> 
> Or more info needed in /usr/{src,ports}/UPDATING?
> 
> 


-- 
Regards,
Bryan Drewery




___
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: svn commit: r318757 - head

2017-05-23 Thread Larry Rosenman
My PostgreSQL buildfarm animal BROKE with this change until I force rebuilt
lang/perl5.24
and all my p5-* ports. 

emulators/qemu-user-static also won’t compile (sbruno@ is on this one).

Poudriere did *NOT* force a fuill rebuild even though freebsd-version *WAS* 
bumped. 

Is there a hazard for others here?

Or more info needed in /usr/{src,ports}/UPDATING?


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
  


___
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: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Larry Rosenman
Current SVN seems to have fixed it (via sobomax@ syslogd commit). 

borg.lerctr.org /usr/src $ svn info;uname -aKU
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 316973
Node Kind: directory
Schedule: normal
Last Changed Author: sobomax
Last Changed Rev: 316973
Last Changed Date: 2017-04-15 13:20:11 -0500 (Sat, 15 Apr 2017)

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #22 r316973: Sat Apr 
15 14:06:54 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
amd64 1200028 1200028
borg.lerctr.org /usr/src $
[borg][

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 4/15/17, 2:13 PM, "Kurt Jaeger" <li...@opsec.eu> wrote:

Hi!

Larry wrote:
> It was with PostgreSQL starting and I also noted Exim, SSHD, and
> others spinning.  Lots of NO BUFFERSPACE in a truss.

Interesting. I had my build host being dead in the
network (no ping, also with bufferspace problems), but I was able
to login via console.

And: It failed to shutdown/reboot properly, with some 200+ unclean
blocks, trying to get them on disk in an seemingly endless loop.
I had to hard-reset the box.

But: It's older, r315141.

-- 
p...@opsec.eu+49 171 3101372 3 years to 
go !



___
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: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Larry Rosenman
On 4/15/17, 1:43 PM, "David Wolfskill"  wrote:

On Sat, Apr 15, 2017 at 04:41:28PM +, Poul-Henning Kamp wrote:
> 
> ...
> >And I understand that the Cloudflare/f-root server issue isn't quite
> >that recent: "The new f-root servers appeared around two weeks ago"
> 
> And isn't the zone cache expiry time around two weeks as well ?
> 

Regardless, I observe that my laptop was (somewhat) affected by this,
but my build machine did not appear to be affected.

The build machine has very few ports install, runs a GENERIC kernel,
and normally runs headless, while the laptop normally runs xdm and
has my (somewhat old-fashioned) set of ports for a user-facing
machine.  But among the ports on which X11 depends is dbus, and
dbus-daemon was one of the processes that was apparently spinning
in CPU without evidence of accomplishing much of anything, so the
X11 environment wasn't usable.  (I was able to login to and use a
vty on the laptop, though.)

Peace,
david


As was my HOME server which does NOT do ANY DNS services (It’s a DNS Client, 
DHCP Client). 

It was with PostgreSQL starting and I also noted Exim, SSHD, and others 
spinning.  Lots of NO BUFFERSPACE in a truss. 

I suspect it’s related to UDP changes in the system. 
 


___
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: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Larry Rosenman
On 4/15/17, 6:53 AM, "O. Hartmann"  wrote:

Recent CURRENT running on a server makes the system booting in multiuser 
mode booting
incredibly slow! On a machine, before I interrupted the booting process 
hanging in
starting postgresql 9.6.2 server, it took > 10 minutes.

Due to a serious bug in CURRENT, I had to disable BPF_JITTER via sysctl
net.bpf_jitter.enable=0

The box also is a syslog "receiving" server for other hosts, syslogd's 
option "-s" isn't
used (just for the record).

I'm back to r316717 now which boots the box fine.

Booting in single-user mode is also quick as expected.

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


I’m seeing similar, and HAVE the syslogd patch applied.   

My system seems to hang with PostgreSQL taking a LONG time to come up, I also 
saw sshd/exim and other processes spinning on a “No Bufferspace availabile” 
(from a truss, no I don’t have the output). 

Something™ is seriously not right here.





___
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: umount_nfs: Current

2017-03-24 Thread Larry Rosenman
I tried my test (umount –t nfs –a && mount –t nfs –a) and no crash. (with ~84G 
inact cached NFS data).

I suspect it helped.  


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 


___
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: umount_nfs: Current

2017-03-23 Thread Larry Rosenman
Patch applied and running – I’ll try the repro here in a day or 2.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 3/23/17, 1:20 PM, "Larry Rosenman" <l...@lerctr.org> wrote:

Ok, I think I have a repro scenario.  I just repro’d it without this patch. 

I’ll apply it and try again.

It takes about 2 days to get enough INACT data that the umount_nfs crashes.


    
    -- 
    Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 3/22/17, 9:20 PM, "Rick Macklem" <rmack...@uoguelph.ca> wrote:

Larry Rosenman wrote:

> Err, I’m at  r315289….
I think the attached patch (only very lightly tested by me) will fix 
this crash.
If you have an easy way to test it, that would be appreciated, rick





___
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: umount_nfs: Current

2017-03-23 Thread Larry Rosenman
Ok, I think I have a repro scenario.  I just repro’d it without this patch. 

I’ll apply it and try again.

It takes about 2 days to get enough INACT data that the umount_nfs crashes.



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 3/22/17, 9:20 PM, "Rick Macklem" <rmack...@uoguelph.ca> wrote:

    Larry Rosenman wrote:

> Err, I’m at  r315289….
I think the attached patch (only very lightly tested by me) will fix this 
crash.
If you have an easy way to test it, that would be appreciated, rick




___
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: umount_nfs: Current

2017-03-22 Thread Larry Rosenman
It’s VERY intermittent ( 

I.E. not easy to reproduce.

Sorry.


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 3/22/17, 9:20 PM, "Rick Macklem" <rmack...@uoguelph.ca> wrote:

    Larry Rosenman wrote:

> Err, I’m at  r315289….
I think the attached patch (only very lightly tested by me) will fix this 
crash.
If you have an easy way to test it, that would be appreciated, rick




___
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: umount_nfs: Current

2017-03-16 Thread Larry Rosenman
Err, I’m at  r315289….


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 3/16/17, 5:51 PM, "Rick Macklem" <rmack...@uoguelph.ca> wrote:

I believe the cause of this crash was fixed by a recent commit
to head r313735 (which was MFC'd to stable/11 and stable/10).

rick

From: owner-freebsd-curr...@freebsd.org <owner-freebsd-curr...@freebsd.org> 
on behalf of Larry Rosenman <l...@lerctr.org>
Sent: Wednesday, March 15, 2017 10:44:33 PM
To: freebsd...@freebsd.org
Cc: freebsd-current@FreeBSD.org
Subject: crash: umount_nfs: Current

Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT.

Lovely crash:

borg.lerctr.org dumped core - see /var/crash/vmcore.1

Wed Mar 15 21:38:53 CDT 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue 
Mar 14 20:55:36 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
amd64

panic: general protection fault

GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 21
instruction pointer = 0x20:0x80a327ae
stack pointer   = 0x28:0xfe535ebb2800
frame pointer   = 0x28:0xfe535ebb2830
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 = 3172 (umount)
trap number = 9
panic: general protection fault
cpuid = 1
time = 1489631515
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe535ebb2440
vpanic() at vpanic+0x19c/frame 0xfe535ebb24c0
panic() at panic+0x43/frame 0xfe535ebb2520
trap_fatal() at trap_fatal+0x322/frame 0xfe535ebb2570
trap() at trap+0x5e/frame 0xfe535ebb2730
calltrap() at calltrap+0x8/frame 0xfe535ebb2730
--- trap 0x9, rip = 0x80a327ae, rsp = 0xfe535ebb2800, rbp = 
0xfe535ebb2830 ---
__mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfe535ebb2830
xprt_unregister() at xprt_unregister+0x28/frame 0xfe535ebb2850
clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 
0xfe535ebb2880
nfs_unmount() at nfs_unmount+0x182/frame 0xfe535ebb28d0
dounmount() at dounmount+0x5c1/frame 0xfe535ebb2950
sys_unmount() at sys_unmount+0x30f/frame 0xfe535ebb2a70
amd64_syscall() at amd64_syscall+0x55a/frame 0xfe535ebb2bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe535ebb2bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x800872b9a, rsp = 
0x7fffde88, rbp = 0x7fffe3c0 ---
Uptime: 2h43m8s
Dumping 5744 out of 131005 
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.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.
done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.
done.
Reading sy

crash: umount_nfs: Current

2017-03-15 Thread Larry Rosenman
.debug...done.
done.
Reading symbols from /boot/kernel/profile.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/profile.ko.debug...done.
done.
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtrace.ko.debug...done.
done.
Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done.
done.
Reading symbols from /boot/kernel/systrace.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/systrace.ko.debug...done.
done.
Reading symbols from /boot/kernel/sdt.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/sdt.ko.debug...done.
done.
Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fasttrap.ko.debug...done.
done.
Reading symbols from /boot/kernel/fbt.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fbt.ko.debug...done.
done.
Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done.
done.
Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done.
done.
Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ipmi.ko.debug...done.
done.
Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ipmi_linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/hwpmc.ko.debug...done.
done.
Reading symbols from /boot/kernel/mfip.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/mfip.ko.debug...done.
done.
Reading symbols from /boot/kernel/ums.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ums.ko.debug...done.
done.
Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/netgraph.ko.debug...done.
done.
Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ng_ether.ko.debug...done.
done.
Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
done.
__curthread () at ./machine/pcpu.h:232
232 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:232
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318
#2  0x80a52c15 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:386
#3  0x80a53206 in vpanic (fmt=, ap=0xfe535ebb2500)
at /usr/src/sys/kern/kern_shutdown.c:779
#4  0x80a53253 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:710
#5  0x80ecd5c2 in trap_fatal (frame=0xfe535ebb2740, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:801
#6  0x80eccb8e in trap (frame=0xfe535ebb2740)
at /usr/src/sys/amd64/amd64/trap.c:197
#7  
#8  __mtx_lock_flags (c=0xdeadc0dedeadc0f6, opts=0, 
file=0x8147e721 "/usr/src/sys/rpc/svc.c", line=380)
at /usr/src/sys/kern/kern_mutex.c:239
#9  0x80cc14b8 in xprt_unregister (xprt=0xf8022e0fce00)
at /usr/src/sys/rpc/svc.c:380
#10 0x80cbc058 in clnt_reconnect_destroy (cl=0xf80146fa3900)
at /usr/src/sys/rpc/clnt_rc.c:500
#11 0x80969972 in nfs_unmount (mp=, 
mntflags=) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:1704
#12 0x80b0b761 in dounmount (mp=0xdeadc0dedeadc0f6, flags=134217728, 
td=0xf8018f2eb000) at /usr/src/sys/kern/vfs_mount.c:1388
#13 0x80b0b11f in sys_unmount (td=0xf8018f2eb000, 
uap=0xfe535ebb2b70) at /usr/src/sys/kern/vfs_mount.c:1215
#14 0x80ecdfea in syscallenter (td=0xf8018f2eb000, 
sa=)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#15 amd64_syscall (td=0xf8018f2eb000, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:902
#16 
Can't read data for section '.eh_frame' in file '/'
(kgdb) 

vmcore / source IS available.

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


Build Fail: -CURRENT

2017-03-04 Thread Larry Rosenman
--- all_subdir_usr.sbin/amd ---

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x13e): undefined reference to 
`xdr_symlinkargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x14c): undefined reference to 
`xdr_diropres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x151): undefined reference to 
`xdr_createargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x15f): undefined reference to 
`xdr_nfsstat'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x164): undefined reference to 
`xdr_diropargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x172): undefined reference to 
`xdr_readdirres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x177): undefined reference to 
`xdr_readdirargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x185): undefined reference to 
`xdr_statfsres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18a): undefined reference to 
`xdr_nfs_fh'

stubs.o: In function `nfsproc_readlink_2_svc':

/usr/src/contrib/amd/hlfsd/stubs.c:356: undefined reference to `xdr_readlinkres'

--- all_subdir_rescue ---

Building /usr/obj/usr/src/rescue/rescue/usr/src/sbin/ipf/ipf/printlookup.o

--- all_subdir_usr.sbin ---

cc: error: linker command failed with exit code 1 (use -v to see invocation)

*** [hlfsd.full] Error code 1

 

--

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

 

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


panic on current during shutdown: panic: racct_adjust_resource: resource 4 usage < 0

2017-01-19 Thread Larry Rosenman
ernel/sdt.ko.debug...done.

done.
Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fasttrap.ko.debug...done.

done.
Reading symbols from /boot/kernel/fbt.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fbt.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done.

done.
Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done.

done.
Reading symbols from /boot/modules/vboxdrv.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ipmi.ko.debug...done.

done.
Reading symbols from /boot/kernel/ipmi_linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ipmi_linux.ko.debug...done.

done.
Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/hwpmc.ko.debug...done.

done.
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/filemon.ko.debug...done.

done.
Reading symbols from /boot/kernel/uhid.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/uhid.ko.debug...done.

done.
Reading symbols from /boot/modules/vboxnetflt.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/netgraph.ko.debug...done.

done.
Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ng_ether.ko.debug...done.

done.
Reading symbols from /boot/modules/vboxnetadp.ko...(no debugging symbols 
found)...done.
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.

done.
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.

done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.

done.
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.

done.
__curthread () at ./machine/pcpu.h:222
222 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:222
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:318
#2  0x80a2ffb5 in kern_reboot (howto=)
at /usr/src/sys/kern/kern_shutdown.c:386
#3  0x80a30590 in vpanic (fmt=, 
ap=0xfe2eb7c188f0)

at /usr/src/sys/kern/kern_shutdown.c:779
#4  0x80a303c6 in kassert_panic (
fmt=0x813ee4fb "%s: resource %d usage < 0")
at /usr/src/sys/kern/kern_shutdown.c:669
#5  0x80a21eca in racct_adjust_resource 
(racct=0xf8001b7c00d0,
resource=4, amount=) at 
/usr/src/sys/kern/kern_racct.c:528

#6  0x80a21acc in racct_set_locked (p=0xf80055f41528,
resource=, amount=0, force=0)
at /usr/src/sys/kern/kern_racct.c:718
#7  0x80a21994 in racct_set (p=0xf80055f41528, resource=4,
amount=0) at /usr/src/sys/kern/kern_racct.c:741
#8  0x80d0f8e7 in vmspace_container_reset (p=)
at /usr/src/sys/vm/vm_map.c:311
#9  vmspace_exit (td=) at /usr/src/sys/vm/vm_map.c:420
#10 0x809f01ab in exit1 (td=, rval=out>,

signo=) at /usr/src/sys/kern/kern_exit.c:399
#11 0x809efc3d in sys_sys_exit (td=, uap=out>)

at /usr/src/sys/kern/kern_exit.c:178
#12 0x80e9a98a in syscallenter (td=0xf80055de6000,
sa=)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#13 amd64_syscall (td=0xf80055de6000, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:902
#14 
Can't read data for section '.eh_frame' in file '/'
(kgdb)

vmcore IS available.


--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: TSC as timecounter makes system lag [-> jhb]

2017-01-15 Thread Larry Rosenman

On 2017-01-14 23:03, Julian Elischer wrote:

On 15/01/2017 10:11 AM, Jia-Shiun Li wrote:
On Fri, Jan 13, 2017 at 8:26 AM, Jia-Shiun Li <jiash...@gmail.com> 
wrote:



Hi all,

since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel 
Pentium

T4200 notebook lagged a lot. System time was running a lot slower,
sometimes even looked like it freezed. Keystroke repeat rate was slow 
too.


Since system time is slow, I tried to change timecounter from default 
TSC

to HPET. And it resumed normal immediately.



Did a binary search. Turns out it was caused by r310177 "Enable
EARLY_AP_STARTUP on amd64 and i386 kernels by default." r310175 does 
not
have this issue. Removing this option from kernel config also solves 
it.


making sure jhb notices this.
FWIW, I noted similar "slowness", and nooptions EARLY_AP_STARTUP makes 
it "normal"

again.

Copyright (c) 1992-2017 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 #13 r311997: Sat Jan 14 22:35:29 CST 2017
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on 
LLVM 3.9.1)

MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128600960 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6
  
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  
Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1>

  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65353601024 (62326 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs


--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


CURRENT:Build Break

2016-10-16 Thread Larry Rosenman
I get the following:
Building /usr/obj/usr/src/sys/VT-LER/if_ptnet.o
/usr/src/sys/dev/netmap/if_ptnet.c:87:10: fatal error: 'net/netmap_virt.h' file 
not found
#include 
 ^
1 error generated.
*** Error code 1

borg.lerctr.org /usr/src # svn up
Updating '.':
At revision 307395.
borg.lerctr.org /usr/src # ^C
borg.lerctr.org /usr/src #

Ideas?

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


Build Break at r306148

2016-09-21 Thread Larry Rosenman
rror-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-self-assign -mno-aes -mno-avx  -std=iso9899:1999 -c 
/usr/src/sys/modules/nxge/../../dev/nxge/xgehal/xgehal-stats.c -o 
xgehal-stats.o

--- all_subdir_oce ---
1 error generated.
*** [oce_if.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/oce
--- all_subdir_nxge ---
--- xgehal-fifo.o ---
1 warning generated.
ctfconvert -L VERSION -g xgehal-fifo.o
--- xgehal-stats.o ---
In file included from 
/usr/src/sys/modules/nxge/../../dev/nxge/xgehal/xgehal-stats.c:30:
In file included from 
/usr/src/sys/dev/nxge/include/xgehal-device.h:1004:
In file included from 
/usr/src/sys/dev/nxge/xgehal/xgehal-device-fp.c:34:

In file included from /usr/src/sys/dev/nxge/include/xgehal-fifo.h:354:
/usr/src/sys/dev/nxge/xgehal/xgehal-fifo-fp.c:593:16: warning: 
explicitly assigning value of variable of type 'xge_hal_fifo_txdl_priv_t 
*' (aka 'struct xge_hal_fifo_txdl_priv_t *') to itself [-Wself-assign]

txdl_priv = txdl_priv; /* Cheat lint */
~ ^ ~
--- all_subdir_netgraph ---
--- all_subdir_netgraph/pptpgre ---
ctfconvert -L VERSION -g ng_pptpgre.o
A failure has been detected in another branch of the parallel make

make[5]: stopped in /usr/src/sys/modules/netgraph/pptpgre
*** [all_subdir_netgraph/pptpgre] Error code 2

make[4]: stopped in /usr/src/sys/modules/netgraph
1 error

make[4]: stopped in /usr/src/sys/modules/netgraph
*** [all_subdir_netgraph] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_oce ---
--- oce_sysctl.o ---
ctfconvert -L VERSION -g oce_sysctl.o
--- all_subdir_otus ---
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/otus
*** [all_subdir_otus] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_oce ---
--- oce_queue.o ---
ctfconvert -L VERSION -g oce_queue.o
1 error

make[4]: stopped in /usr/src/sys/modules/oce
*** [all_subdir_oce] Error code 2

make[3]: stopped in /usr/src/sys/modules
--- all_subdir_nxge ---
1 warning generated.
ctfconvert -L VERSION -g xgehal-stats.o
--- xgehal-device.o ---
1 warning generated.
ctfconvert -L VERSION -g xgehal-device.o
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/sys/modules/nxge
*** [all_subdir_nxge] Error code 2

make[3]: stopped in /usr/src/sys/modules
4 errors

make[3]: stopped in /usr/src/sys/modules
*** [modules-all] Error code 2

make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
1 error

make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
*** [buildkernel] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
*** [buildkernel] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src
^C
[1]   Done(2) nohup make -j 8 buildkernel >make.kern.out 
2>&1

# svn up
Updating '.':
At revision 306148.
#

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-08-03 Thread Larry Rosenman

I didn't (realize|know) Imre was on vacation.

Thanks Adrian!

On 2016-08-03 12:36, Adrian Chadd wrote:

I've no idea, sorry. :(

Imre's out for another week, so let him finish his holiday first. :)


-a


On 3 August 2016 at 10:28, Larry Rosenman <l...@lerctr.org> wrote:

Anyone?
On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote:

I recompiled security/wpa_supplicant and seem to be able to get
associated.

I'm not sure what is going on.

Any suggestions?

On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote:
> Even with that reverted, I'm still having iffy connections.
>
> Current code:
>
> FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 
16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 
121
>
> Current diff to that SVN Rev:
>
> Index: sys/dev/iwm/if_iwm.c
> ===
> --- sys/dev/iwm/if_iwm.c(revision 303597)
> +++ sys/dev/iwm/if_iwm.c(working copy)
> @@ -3357,15 +3357,12 @@
> uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
>
> if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
> -   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
> -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
> -   } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
> -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> -   } else {
> -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
> -   }
> +   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
> +   tx->pm_frame_timeout = htole16(3);
> +   else
> +   tx->pm_frame_timeout = htole16(2);
> } else {
> -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> +   tx->pm_frame_timeout = htole16(0);
> }
>
> if (hdrlen & 3) {
> Index: sys/dev/iwm/if_iwmreg.h
> ===
> --- sys/dev/iwm/if_iwmreg.h (revision 303597)
> +++ sys/dev/iwm/if_iwmreg.h (working copy)
> @@ -4244,18 +4244,6 @@
> IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
>  }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
>
> -/**
> - * enum iwm_tx_pm_timeouts - pm timeout values in TX command
> - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
> - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
> - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
> - */
> -enum iwm_tx_pm_timeouts {
> -   IWM_PM_FRAME_NONE   = 0,
> -   IWM_PM_FRAME_MGMT   = 2,
> -   IWM_PM_FRAME_ASSOC  = 3,
> -};
> -
>  /*
>   * TX command security control
>   */
>
>
>
> Scan Debug:
> http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt
>
> What next?
>
> On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> > +imre,
> >
> > Hi! Larry is having issues with r303418. Would you be able to help him out?
> >
> > (If it's not too bad, can we back this out until you figure out what's
> > going on?)
> >
> > Thanks!
> >
> >
> > -a
> >
> >
> > On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
> > > On 2016-07-28 20:02, Adrian Chadd wrote:
> > >>
> > >> Hi,
> > >>
> > >> Which commit(s) did you revert?
> > >>
> > >>
> > >>
> > >> -a
> > >
> > >
> > > revert r303418
> > >
> > > and now it connects again.
> > >
> > >
> > > --
> > > Larry Rosenman http://www.lerctr.org/~ler
> > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

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


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-08-03 Thread Larry Rosenman
Anyone?
On Sun, Jul 31, 2016 at 09:19:02PM -0500, Larry Rosenman wrote:
> I recompiled security/wpa_supplicant and seem to be able to get
> associated. 
> 
> I'm not sure what is going on. 
> 
> Any suggestions?
> 
> On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote:
> > Even with that reverted, I'm still having iffy connections. 
> > 
> > Current code:
> > 
> > FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 
> > 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 
> > 121 121
> > 
> > Current diff to that SVN Rev:
> > 
> > Index: sys/dev/iwm/if_iwm.c
> > ===
> > --- sys/dev/iwm/if_iwm.c(revision 303597)
> > +++ sys/dev/iwm/if_iwm.c(working copy)
> > @@ -3357,15 +3357,12 @@
> > uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
> >  
> > if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
> > -   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
> > -   } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> > -   } else {
> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
> > -   }
> > +   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
> > +   tx->pm_frame_timeout = htole16(3);
> > +   else
> > +   tx->pm_frame_timeout = htole16(2);
> > } else {
> > -   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> > +   tx->pm_frame_timeout = htole16(0);
> > }
> >  
> > if (hdrlen & 3) {
> > Index: sys/dev/iwm/if_iwmreg.h
> > ===
> > --- sys/dev/iwm/if_iwmreg.h (revision 303597)
> > +++ sys/dev/iwm/if_iwmreg.h (working copy)
> > @@ -4244,18 +4244,6 @@
> > IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
> >  }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
> >  
> > -/**
> > - * enum iwm_tx_pm_timeouts - pm timeout values in TX command
> > - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
> > - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
> > - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
> > - */
> > -enum iwm_tx_pm_timeouts {
> > -   IWM_PM_FRAME_NONE   = 0,
> > -   IWM_PM_FRAME_MGMT   = 2,
> > -   IWM_PM_FRAME_ASSOC  = 3,
> > -};
> > -
> >  /*
> >   * TX command security control
> >   */
> > 
> > 
> > 
> > Scan Debug:
> > http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt
> > 
> > What next?
> > 
> > On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> > > +imre,
> > > 
> > > Hi! Larry is having issues with r303418. Would you be able to help him 
> > > out?
> > > 
> > > (If it's not too bad, can we back this out until you figure out what's
> > > going on?)
> > > 
> > > Thanks!
> > > 
> > > 
> > > -a
> > > 
> > > 
> > > On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
> > > > On 2016-07-28 20:02, Adrian Chadd wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> Which commit(s) did you revert?
> > > >>
> > > >>
> > > >>
> > > >> -a
> > > >
> > > >
> > > > revert r303418
> > > >
> > > > and now it connects again.
> > > >
> > > >
> > > > --
> > > > Larry Rosenman http://www.lerctr.org/~ler
> > > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> > 
> > -- 
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-07-31 Thread Larry Rosenman
I recompiled security/wpa_supplicant and seem to be able to get
associated. 

I'm not sure what is going on. 

Any suggestions?

On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote:
> Even with that reverted, I'm still having iffy connections. 
> 
> Current code:
> 
> FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 
> 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 
> 121
> 
> Current diff to that SVN Rev:
> 
> Index: sys/dev/iwm/if_iwm.c
> ===
> --- sys/dev/iwm/if_iwm.c  (revision 303597)
> +++ sys/dev/iwm/if_iwm.c  (working copy)
> @@ -3357,15 +3357,12 @@
>   uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
>  
>   if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
> - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
> - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> - } else {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
> - }
> + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
> + tx->pm_frame_timeout = htole16(3);
> + else
> + tx->pm_frame_timeout = htole16(2);
>   } else {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> + tx->pm_frame_timeout = htole16(0);
>   }
>  
>   if (hdrlen & 3) {
> Index: sys/dev/iwm/if_iwmreg.h
> ===
> --- sys/dev/iwm/if_iwmreg.h   (revision 303597)
> +++ sys/dev/iwm/if_iwmreg.h   (working copy)
> @@ -4244,18 +4244,6 @@
>   IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
>  }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
>  
> -/**
> - * enum iwm_tx_pm_timeouts - pm timeout values in TX command
> - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
> - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
> - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
> - */
> -enum iwm_tx_pm_timeouts {
> - IWM_PM_FRAME_NONE   = 0,
> - IWM_PM_FRAME_MGMT   = 2,
> - IWM_PM_FRAME_ASSOC  = 3,
> -};
> -
>  /*
>   * TX command security control
>   */
> 
> 
> 
> Scan Debug:
> http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt
> 
> What next?
> 
> On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> > +imre,
> > 
> > Hi! Larry is having issues with r303418. Would you be able to help him out?
> > 
> > (If it's not too bad, can we back this out until you figure out what's
> > going on?)
> > 
> > Thanks!
> > 
> > 
> > -a
> > 
> > 
> > On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
> > > On 2016-07-28 20:02, Adrian Chadd wrote:
> > >>
> > >> Hi,
> > >>
> > >> Which commit(s) did you revert?
> > >>
> > >>
> > >>
> > >> -a
> > >
> > >
> > > revert r303418
> > >
> > > and now it connects again.
> > >
> > >
> > > --
> > > Larry Rosenman http://www.lerctr.org/~ler
> > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-07-31 Thread Larry Rosenman
Even with that reverted, I'm still having iffy connections. 

Current code:

FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 
CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 121

Current diff to that SVN Rev:

Index: sys/dev/iwm/if_iwm.c
===
--- sys/dev/iwm/if_iwm.c(revision 303597)
+++ sys/dev/iwm/if_iwm.c(working copy)
@@ -3357,15 +3357,12 @@
uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
 
if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
-   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
-   } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
-   } else {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
-   }
+   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
+   tx->pm_frame_timeout = htole16(3);
+   else
+   tx->pm_frame_timeout = htole16(2);
} else {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
+   tx->pm_frame_timeout = htole16(0);
}
 
if (hdrlen & 3) {
Index: sys/dev/iwm/if_iwmreg.h
===
--- sys/dev/iwm/if_iwmreg.h (revision 303597)
+++ sys/dev/iwm/if_iwmreg.h (working copy)
@@ -4244,18 +4244,6 @@
IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
 }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
 
-/**
- * enum iwm_tx_pm_timeouts - pm timeout values in TX command
- * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
- * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
- * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
- */
-enum iwm_tx_pm_timeouts {
-   IWM_PM_FRAME_NONE   = 0,
-   IWM_PM_FRAME_MGMT   = 2,
-   IWM_PM_FRAME_ASSOC  = 3,
-};
-
 /*
  * TX command security control
  */



Scan Debug:
http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt

What next?

On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> +imre,
> 
> Hi! Larry is having issues with r303418. Would you be able to help him out?
> 
> (If it's not too bad, can we back this out until you figure out what's
> going on?)
> 
> Thanks!
> 
> 
> -a
> 
> 
> On 28 July 2016 at 18:05, Larry Rosenman <l...@lerctr.org> wrote:
> > On 2016-07-28 20:02, Adrian Chadd wrote:
> >>
> >> Hi,
> >>
> >> Which commit(s) did you revert?
> >>
> >>
> >>
> >> -a
> >
> >
> > revert r303418
> >
> > and now it connects again.
> >
> >
> > --
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-07-28 Thread Larry Rosenman

On 2016-07-28 20:02, Adrian Chadd wrote:

Hi,

Which commit(s) did you revert?



-a


revert r303418

and now it connects again.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: IWM(7260), no connect

2016-07-28 Thread Larry Rosenman
That  seems to fix it, and I'm sorry I missed this in my Inbox earlier. 


On Thu, Jul 28, 2016 at 12:12:42PM +0300, Andriy Voskoboinyk wrote:
> Thu, 28 Jul 2016 05:39:55 +0300  ???? Larry Rosenman  
> <l...@lerctr.org>:
> 
> Try to revert r303418 (as I can see, r303416 and/or r303413 are not the  
> reason
> of this).
> 
> In case, if this will not help, you can try to add
> wlandebug_wlan0="state+scan+auth+assoc"
> into rc.conf to see where it fails.
> 
> > I'm running today's top of tree, and it doesn't seem to want to connect:
> >
> >
> > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > 
> > options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
> > ether 20:47:47:73:07:5f
> > inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
> > inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
> > inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
> > nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> > media: Ethernet autoselect (1000baseT )
> > status: active
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> > options=63<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> > inet 127.0.0.1 netmask 0xff00
> > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> > groups: lo
> > wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric  
> > 0 mtu 1500
> > ether 58:91:cf:1a:45:69
> > inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
> > nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
> > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
> > status: no carrier
> > ssid "" channel 8 (2447 MHz 11g)
> > regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
> > deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
> > roaming MANUAL
> > groups: wlan
> >
> >
> > hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086  
> > rev=0x07 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Skylake Host Bridge/DRAM Registers'
> > class  = bridge
> > subclass   = HOST-PCI
> > pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086  
> > rev=0x07 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Skylake PCIe Controller (x16)'
> > class  = bridge
> > subclass   = PCI-PCI
> > pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086  
> > rev=0x07 hdr=0x01
> > vendor = 'Intel Corporation'
> > device = 'Skylake PCIe Controller (x8)'
> > class  = bridge
> > subclass   = PCI-PCI
> > vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086  
> > rev=0x06 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'HD Graphics 530'
> > class  = display
> > subclass   = VGA
> > none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086  
> > rev=0x07 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Skylake Processor Thermal Subsystem'
> > class  = dasp
> > xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H USB 3.0 xHCI Controller'
> > class  = serial bus
> > subclass   = USB
> > none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H Thermal subsystem'
> > class  = dasp
> > none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H Serial IO I2C Controller'
> > class  = dasp
> > none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H CSME HECI'
> > class  = simple comms
> > ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086  
> > rev=0x31 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'Sunrise Point-H SATA Controller [AHCI mode]'
>

Re: IWM(7260), no connect

2016-07-28 Thread Larry Rosenman

negative.  no reponse (except for this one) at all.
:(


On 2016-07-28 18:07, Adrian Chadd wrote:

Hi,

Andriy responded?


-adrian


On 28 July 2016 at 16:04, Larry Rosenman <l...@lerctr.org> wrote:

Anyone?


On 2016-07-27 21:39, Larry Rosenman wrote:


I'm running today's top of tree, and it doesn't seem to want to 
connect:



re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500


options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 
autoconf
inet 192.168.200.246 netmask 0xfc00 broadcast 
192.168.203.255

nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=63<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 
0x3

nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy 
ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS 
wme

roaming MANUAL
groups: wlan


hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 
chip=0x19108086

rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 
chip=0x19018086

rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 
chip=0x19058086

rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 
chip=0x191b8086

rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 
chip=0x19038086

rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 
chip=0xa12f8086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 
chip=0xa1318086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 
chip=0xa1608086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 
chip=0xa13a8086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 
chip=0xa1038086

rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 
chip=0xa1108086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 
chip=0xa1148086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 
chip=0xa1158086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 
chip=0xa1168086

rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:   

Re: IWM(7260), no connect

2016-07-28 Thread Larry Rosenman

Anyone?

On 2016-07-27 21:39, Larry Rosenman wrote:
I'm running today's top of tree, and it doesn't seem to want to 
connect:



re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500


options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 20:47:47:73:07:5f
inet6 fe80::2247:47ff:fe73:75f%re0 prefixlen 64 scopeid 0x1
inet6 2001:470:1f0f:42c:2247:47ff:fe73:75f prefixlen 64 autoconf
inet 192.168.200.246 netmask 0xfc00 broadcast 192.168.203.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT )
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=63<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST>
metric 0 mtu 1500
ether 58:91:cf:1a:45:69
inet6 fe80::5a91:cfff:fe1a:4569%wlan0 prefixlen 64 scopeid 0x3
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 8 (2447 MHz 11g)
regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 10 scanvalid 60 protmode CTS wme
roaming MANUAL
groups: wlan


hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086
rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086
rev=0x07 hdr=0x01
vendor = 'Intel Corporation'
device = 'Skylake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'HD Graphics 530'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Skylake Processor Thermal Subsystem'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Serial IO I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086
rev=0xf1 hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07061028 chip=0xa14e8086
rev=0x31 hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class  = bridge
subclass   = PCI-ISA
none4@pci0:0:31:2:  class=

IWM(7260), no connect

2016-07-27 Thread Larry Rosenman
086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PMC'
class  = memory
hdac0@pci0:0:31:3:  class=0x040300 card=0x07061028 chip=0xa1708086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H HD Audio'
class  = multimedia
subclass   = HDA
none5@pci0:0:31:4:  class=0x0c0500 card=0x07061028 chip=0xa1238086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SMBus'
class  = serial bus
subclass   = SMBus
vgapci0@pci0:2:0:0: class=0x030200 card=0x07061028 chip=0x139b10de rev=0xa2 
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GM107M [GeForce GTX 960M]'
class  = display
subclass   = 3D
re0@pci0:4:0:0: class=0x02 card=0x07061028 chip=0x816810ec rev=0x10 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class  = network
subclass   = ethernet
iwm0@pci0:5:0:0:class=0x028000 card=0xc0708086 chip=0x08b18086 rev=0x6b 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Wireless 7260'
class  = network
none6@pci0:6:0:0:   class=0xff card=0x522a10ec chip=0x522a10ec rev=0x01 
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS522A PCI Express Card Reader'


What other info do we need?



Path: /usr/src
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 303419
Node Kind: directory
Schedule: normal
Last Changed Author: bdrewery
Last Changed Rev: 303419
Last Changed Date: 2016-07-27 16:45:11 -0500 (Wed, 27 Jul 2016)


FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r303419: Wed Jul 27 21:22:29 
CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 121
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: callout_drain either broken or man page needs updating

2016-07-15 Thread Larry Rosenman

On 2016-07-15 13:34, Matthew Macy wrote:

 On Fri, 15 Jul 2016 01:43:03 -0700 Gleb Smirnoff
<gleb...@freebsd.org> wrote 
 > On Thu, Jul 14, 2016 at 10:14:46PM -0700, Matthew Macy wrote:
 > M>  > On 07/15/16 05:45, Matthew Macy wrote:
 > M>  > > glebius last commit needs some further re-work.
 > M>  >
 > M>  > Glebius commit needs to be backed out, at least the API change 
that

 > M>  > changes the return value when calling callout_stop() when the
callout is
 > M>  > scheduled and being serviced. Simply because there is code
out there,
 > M>  > like Mattew and others have discovered that is "refcounting" 
on the
 > M>  > callout_reset() and expecting that a subsequent callout_stop() 
will

 > M>  > return 1 to "unref".
 > M>
 > M> Yes. This is the cause of the "refcnt 0 on LLE at boot..." 
regression.


I misread his comment on the reason for the failure. But, the failure
is caused by a regression in callout_stop.

 > No it isn't. The regression is caused by unintentional change of 
return

 > value for never scheduled callout. The fix is now being tested, see
PR 210884.

Thanks. Let me know when I can update.
-M

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




URL: https://svnweb.freebsd.org/changeset/base/302894
has the fix in HEAD.

(It's a one-liner).

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: panic with tcp timers

2016-07-14 Thread Larry Rosenman

On 2016-07-14 12:01, Julien Charbon wrote:

Hi,

On 6/20/16 11:55 AM, Julien Charbon wrote:

On 6/20/16 9:39 AM, Gleb Smirnoff wrote:

On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
J> > Comparing stable/10 and head, I see two changes that could
J> > affect that:
J> >
J> > - callout_async_drain
J> > - switch to READ lock for inp info in tcp timers
J> >
J> > That's why you are in To, Julien and Hans :)
J> >
J> > We continue investigating, and I will keep you updated.
J> > However, any help is welcome. I can share cores.

Now, spending some time with cores and adding a bunch of
extra CTRs, I have a sequence of events that lead to the
panic. In short, the bug is in the callout system. It seems
to be not relevant to the callout_async_drain, at least for
now. The transition to READ lock unmasked the problem, that's
why NetflixBSD 10 doesn't panic.

The panic requires heavy contention on the TCP info lock.

[CPU 1] the callout fires, tcp_timer_keep entered
[CPU 1] blocks on INP_INFO_RLOCK(_tcbinfo);
[CPU 2] schedules the callout
[CPU 2] tcp_discardcb called
[CPU 2] callout successfully canceled
[CPU 2] tcpcb freed
[CPU 1] unblocks... panic

When the lock was WLOCK, all contenders were resumed in a
sequence they came to the lock. Now, that they are readers,
once the lock is released, readers are resumed in a "random"
order, and this allows tcp_discardcb to go before the old
running callout, and this unmasks the panic.


 Highly interesting.  I should be able to reproduce that (will be 
useful

for testing the corresponding fix).


 Finally, I was able to reproduce it (without glebius fix).   The trick
was to really lower TCP keep timer expiration:

$ sysctl -a | grep tcp.keep
net.inet.tcp.keepidle: 720
net.inet.tcp.keepintvl: 75000
net.inet.tcp.keepinit: 75000
net.inet.tcp.keepcnt: 8
$ sudo bash -c "sysctl net.inet.tcp.keepidle=10 && sysctl
net.inet.tcp.keepintvl=50 && sysctl net.inet.tcp.keepinit=10"
Password:
net.inet.tcp.keepidle: 720 -> 10
net.inet.tcp.keepintvl: 75000 -> 50
net.inet.tcp.keepinit: 75000 -> 10

 Note: It will certainly close all your ssh connections to the tested
server.

 Now I will test in order:

#1. glebius fix
https://svnweb.freebsd.org/base?view=revision=302350

#2. rss extra fix
https://reviews.freebsd.org/D7135

#3. rrs TCP Timer cleanup
https://reviews.freebsd.org/D7136

 My panic for reference:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 10; apic id = 28
[root@atlas-dl360-4 ~]# instruction pointer = 
0x20:0x80c346f1

stack pointer   = 0x28:0xfe1f29b848b0
frame pointer   = 0x28:0xfe1f29b848e0
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 = 12 (swi4: clock (4))
trap number = 9
panic: general protection fault
cpuid = 10
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1f29b844a0
vpanic() at vpanic+0x182/frame 0xfe1f29b84520
panic() at panic+0x43/frame 0xfe1f29b84580
trap_fatal() at trap_fatal+0x351/frame 0xfe1f29b845e0
trap() at trap+0x820/frame 0xfe1f29b847f0
calltrap() at calltrap+0x8/frame 0xfe1f29b847f0
--- trap 0x9, rip = 0x80c346f1, rsp = 0xfe1f29b848c0, rbp =
0xfe1f29b848e0 ---
tcp_timer_keep() at tcp_timer_keep+0x51/frame 0xfe1f29b848e0
softclock_call_cc() at softclock_call_cc+0x19c/frame 0xfe1f29b849c0
softclock() at softclock+0x47/frame 0xfe1f29b849e0
intr_event_execute_handlers() at intr_event_execute_handlers+0x96/frame
0xfe1f29b84a20
ithread_loop() at ithread_loop+0xa6/frame 0xfe1f29b84a70
fork_exit() at fork_exit+0x84/frame 0xfe1f29b84ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe1f29b84ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---

--
Julien



please see also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: refcnt 0 on LLE at boot....

2016-07-07 Thread Larry Rosenman
Thanks for that.  I've added myself to the cc list, and a comment about 
having 2 vmcore's.



On 2016-07-07 08:28, Edward Tomasz Napierała wrote:

FWIW, I'm seeing this too.  I've filed a PR:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884

On 0707T0813, Larry Rosenman wrote:
and now it's been up for 13+ hours.  I do have both VMCORE's from the 
2

crashes.



On 2016-07-06 18:22, Larry Rosenman wrote:
> Got a similar crash a few minutes later.
>
>
> On 2016-07-06 18:17, Larry Rosenman wrote:
>> First boot, and I got the following panic.  2nd boot ran just fine.
>>
>>
>> borg.lerctr.org dumped core - see /var/crash/vmcore.0
>>
>> Wed Jul  6 18:13:34 CDT 2016
>>
>> FreeBSD borg.lerctr.org 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #5 r302379:
>> Wed Jul  6 16:59:11 CDT 2016
>> r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64
>>
>> panic: bogus refcnt 0 on lle 0xf800aa941200
>>
>> 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:
>> Copyright (c) 1992-2016 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 11.0-ALPHA6 #5 r302379: Wed Jul  6 16:59:11 CDT 2016
>> r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
>> LLVM 3.8.0)
>> can't re-use a leaf (ixl_rx_miss_bufs)!
>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
>>MEMGUARD map base: 0xfe40
>>MEMGUARD map size: 128604256 KBytes
>> VT(vga): resolution 640x480
>> CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz
>> K8-class CPU)
>>   Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17
>> Stepping=6
>>
>> 
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>
>> 
Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1>
>>   AMD Features=0x20100800<SYSCALL,NX,LM>
>>   AMD Features2=0x1
>>   VT-x: HLT,PAUSE
>>   TSC: P-state invariant, performance statistics
>> real memory  = 68719476736 (65536 MB)
>> avail memory = 65382842368 (62353 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table: 
>> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
>> FreeBSD/SMP: 2 package(s) x 4 core(s)
>> random: unblocking device.
>> ioapic0  irqs 0-23 on motherboard
>> ioapic1  irqs 24-47 on motherboard
>> random: entropy device external interface
>> netmap: loaded module
>> module_register_init: MOD_LOAD (vesa, 0x80f2cb40, 0) error 19
>> kbd1 at kbdmux0
>> vtvga0:  on motherboard
>> cryptosoft0:  on motherboard
>> acpi0:  on motherboard
>> acpi0: Power Button (fixed)
>> unknown: I/O range not supported
>> cpu0:  on acpi0
>> cpu1:  on acpi0
>> cpu2:  on acpi0
>> cpu3:  on acpi0
>> cpu4:  on acpi0
>> cpu5:  on acpi0
>> cpu6:  on acpi0
>> cpu7:  on acpi0
>> hpet0:  iomem 0xfed0-0xfed003ff irq
>> 0,8 on acpi0
>> Timecounter "HPET" frequency 14318180 Hz quality 950
>> Event timer "HPET" frequency 14318180 Hz quality 350
>> Event timer "HPET1" frequency 14318180 Hz quality 340
>> Event timer "HPET2" frequency 14318180 Hz quality 340
>> atrtc0:  port 0x70-0x71 on acpi0
>> Event timer "RTC" frequency 32768 Hz quality 0
>> attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> Event timer "i8254" frequency 1193182 Hz quality 100
>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
>> pcib0:  port 0xcf8-0xcff on acpi0
>> pci0:  on pcib0
>> pcib1:  at device 2.0 on pci0
>> pci1:  on pcib1
>> pcib2:  irq 16 at device 0.0 on pci1
>> pci2:  on pcib2

Re: refcnt 0 on LLE at boot....

2016-07-07 Thread Larry Rosenman
and now it's been up for 13+ hours.  I do have both VMCORE's from the 2 
crashes.




On 2016-07-06 18:22, Larry Rosenman wrote:

Got a similar crash a few minutes later.


On 2016-07-06 18:17, Larry Rosenman wrote:

First boot, and I got the following panic.  2nd boot ran just fine.


borg.lerctr.org dumped core - see /var/crash/vmcore.0

Wed Jul  6 18:13:34 CDT 2016

FreeBSD borg.lerctr.org 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #5 r302379:
Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: bogus refcnt 0 on lle 0xf800aa941200

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:
Copyright (c) 1992-2016 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 11.0-ALPHA6 #5 r302379: Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
can't re-use a leaf (ixl_rx_miss_bufs)!
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128604256 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz 
K8-class CPU)
  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  
Stepping=6


Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65382842368 (62353 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
random: entropy device external interface
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f2cb40, 0) error 19
kbd1 at kbdmux0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 
0,8 on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x2000-0x201f
mem 0xd922-0xd923,0xd920-0xd921 irq 18 at device 0.0
on pci6
em0: Using an MSI interrupt
em0: Ethernet address: 00:30:48:f2:29:9c
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em1: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x2020-0x203f
mem 0xd926-0xd927,0xd924-0xd925 irq 19 at device 0.1
on pci6
em1: Using an MSI interrupt
em1: Ethernet address: 00:30:48:f2:29:9d
em1: netmap queues/slots: TX 1/1024, RX 1/1024
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
vgapci0:  port 0x3000-0x307f mem
0xd800-0xd8ff,0xc000-0xc7ff,0xc800-0xc9ff irq
36 at device 0.0 on pci8
hdac0:  mem 0xd900-0xd9003fff irq 37
at device 0.1 on pci8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pcib10:  irq 17 at device 28.0 on pci0
pcib10: [GIANT-LOCKED]
pci10:  on pcib10
p

Re: refcnt 0 on LLE at boot....

2016-07-06 Thread Larry Rosenman

Got a similar crash a few minutes later.


On 2016-07-06 18:17, Larry Rosenman wrote:

First boot, and I got the following panic.  2nd boot ran just fine.


borg.lerctr.org dumped core - see /var/crash/vmcore.0

Wed Jul  6 18:13:34 CDT 2016

FreeBSD borg.lerctr.org 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #5 r302379:
Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: bogus refcnt 0 on lle 0xf800aa941200

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:
Copyright (c) 1992-2016 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 11.0-ALPHA6 #5 r302379: Wed Jul  6 16:59:11 CDT 2016
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
can't re-use a leaf (ixl_rx_miss_bufs)!
MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128604256 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65382842368 (62353 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
random: entropy device external interface
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f2cb40, 0) error 19
kbd1 at kbdmux0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 
on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x2000-0x201f
mem 0xd922-0xd923,0xd920-0xd921 irq 18 at device 0.0
on pci6
em0: Using an MSI interrupt
em0: Ethernet address: 00:30:48:f2:29:9c
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em1: <Intel(R) PRO/1000 Network Connection 7.6.1-k> port 0x2020-0x203f
mem 0xd926-0xd927,0xd924-0xd925 irq 19 at device 0.1
on pci6
em1: Using an MSI interrupt
em1: Ethernet address: 00:30:48:f2:29:9d
em1: netmap queues/slots: TX 1/1024, RX 1/1024
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
vgapci0:  port 0x3000-0x307f mem
0xd800-0xd8ff,0xc000-0xc7ff,0xc800-0xc9ff irq
36 at device 0.0 on pci8
hdac0:  mem 0xd900-0xd9003fff irq 37
at device 0.1 on pci8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pcib10:  irq 17 at device 28.0 on pci0
pcib10: [GIANT-LOCKED]
pci10:  on pcib10
pcib11:  irq 32 at device 0.0 on pci10
pci11:  on pcib11
pcm0:  port 0x4080-0x409f,0x4000-0x407f irq
32 at device 0.0 on pci11
pcm

refcnt 0 on LLE at boot....

2016-07-06 Thread Larry Rosenman
oaded symbols for /boot/kernel/ipmi_linux.ko
Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/hwpmc.ko.debug...done.
done.
Loaded symbols for /boot/kernel/hwpmc.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/uhid.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/uhid.ko.debug...done.
done.
Loaded symbols for /boot/kernel/uhid.ko
#0  doadump (textdump=1) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=1) at pcpu.h:221
#1  0x80a48945 in kern_reboot (howto=)
at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x80a48f1b in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0x80a48d56 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:649
#4  0x80b351d6 in llentry_free (lle=)
at /usr/src/sys/net/if_llatbl.c:432
#5  0x80c5c90f in nd6_cache_lladdr (ifp=0xf80068d65800, 
from=, lladdr=, 
lladdrlen=, type=134, code=0)
at /usr/src/sys/netinet6/nd6.c:1972
#6  0x80c62f57 in nd6_ra_input (m=, 
off=, icmp6len=)
at /usr/src/sys/netinet6/nd6_rtr.c:437
#7  0x80c3ab03 in icmp6_input (mp=, 
offp=, proto=)
at /usr/src/sys/netinet6/icmp6.c:798
#8  0x80c50e90 in ip6_input (m=Cannot access memory at address 0x0
)
at /usr/src/sys/netinet6/ip6_input.c:921
#9  0x80b47470 in netisr_dispatch_src (proto=6, source=0, 
m=0xf80068dfc600) at /usr/src/sys/net/netisr.c:1121
#10 0x80b3209a in ether_demux (ifp=, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:850
#11 0x80b32e90 in ether_nh_input (m=)
at /usr/src/sys/net/if_ethersubr.c:639
#12 0x80b47470 in netisr_dispatch_src (proto=5, source=0, 
m=0xf80068dfc600) at /usr/src/sys/net/netisr.c:1121
#13 0x80b32402 in ether_input (ifp=, m=0x0)
at /usr/src/sys/net/if_ethersubr.c:759
#14 0x80b2ee8a in if_input (ifp=0x0, sendmp=0x0)
at /usr/src/sys/net/if.c:3956
#15 0x80523a6c in em_rxeof (count=99)
at /usr/src/sys/dev/e1000/if_em.c:4872
#16 0x805250b0 in em_handle_que (context=0xfe1eaa699000, 
pending=) at /usr/src/sys/dev/e1000/if_em.c:1598
#17 0x80a9a23c in taskqueue_run_locked (queue=)
at /usr/src/sys/kern/subr_taskqueue.c:465
#18 0x80a9ad38 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:719
#19 0x80a0ba54 in fork_exit (
callout=0x80a9acb0 , 
arg=0xfe1eaa69b730, frame=0xfe2dfe57bc00)
at /usr/src/sys/kern/kern_fork.c:1038
#20 0x80e943fe in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:611
#21 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) 

vmcore IS available.

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: HWPMC on SkyLake

2016-06-14 Thread Larry Rosenman
I have not.  

On 2016-06-14 10:06, Doug Rabson wrote:

> Did you get any feedback on this? I would like to be able to use hwpmc but my 
> desktop is a recent skylake and I also get the 'hwpc_core: unknown PMC 
> architecture: 4' error.
> 
> CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.14-MHz K8-class CPU)
> Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
> AMD Features2=0x121<LAHF,ABM,Prefetch>
> Structured Extended 
> Features=0x29c6fbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
> TSC: P-state invariant, performance statistics
> 
> hwpc_core: unknown PMC architecture: 4
> hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI>
> 
> On 20 February 2016 at 12:49, Larry Rosenman <l...@lerctr.org> wrote:
> 
>> Is there anything I can do to help:
>> 
>> hwpc_core: unknown PMC architecture: 4
>> hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI>
>> 
>> CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU)
>> Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>> Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>> AMD Features2=0x121<LAHF,ABM,Prefetch>
>> Structured Extended 
>> Features=0x29c6fbf<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
>> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
>> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>> TSC: P-state invariant, performance statistics
>> 
>> -- 
>> Larry Rosenman http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640 [1] E-Mail: l...@lerctr.org
>> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
>> ___
>> 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"

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 

Links:
--
[1] tel:%2B1%20214-642-9640
___
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: boot with floppy enabled doesn't.....

2016-05-03 Thread Larry Rosenman

On 2016-05-03 14:54, Joel Dahl wrote:

On Tue, May 03, 2016 at 10:21:25AM -0500, Larry Rosenman wrote:

On 2016-05-03 05:49, Joel Dahl wrote:
> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
>> On a current -CURRENT if my Floppy disk controller and device are
>> ENABLED, we do NOT pass mount root, and the floppy disk
>> light is ON.
>
> Just a "me too". But this is with VMware Fusion. If I disable the
> floppy from
> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
Thanks for posting that I'm not the only one, and it's not flakey
hardware.


I forgot to mention that -CURRENT from three weeks ago works. I rebuilt
-CURRENT today and now it hangs.
As I said in my Original post, April 18 works, not sure when it broke 
after that :(


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: boot with floppy enabled doesn't.....

2016-05-03 Thread Larry Rosenman

On 2016-05-03 05:49, Joel Dahl wrote:

On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:

On a current -CURRENT if my Floppy disk controller and device are
ENABLED, we do NOT pass mount root, and the floppy disk
light is ON.


Just a "me too". But this is with VMware Fusion. If I disable the 
floppy from

BIOS, the virtual machine boots. If I leave it enabled, it hangs.
Thanks for posting that I'm not the only one, and it's not flakey 
hardware.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: boot with floppy enabled doesn't.....

2016-05-02 Thread Larry Rosenman

On 2016-05-02 13:29, John Baldwin wrote:

On Monday, May 02, 2016 12:54:32 PM Larry Rosenman wrote:

On 2016-05-02 12:27, Larry Rosenman wrote:
> On 2016-05-02 11:57, John Baldwin wrote:
>> On Saturday, April 30, 2016 10:36:53 PM Larry Rosenman wrote:
>>> On a current -CURRENT if my Floppy disk controller and device are
>>> ENABLED, we do NOT pass mount root, and the floppy disk
>>> light is ON.
>>>
>>> If I disable the floppy controller/drive in the BIOS, we boot.
>>>
>>> This started after April 18.
>>>
>>> I'm not sure what info to gather.
>>
>> I recently changed some things in the fdc(4) driver that are the
>> first suspect.  You are stuck at the mountroot prompt?  Is your
>> root filesystem on the floppy or on something else?
> The system does mount root, but never gets to the RC Scripts.  Root is
> on ZFS, and NOTHING is in the floppy drive.
Oh, and it seems(!) like it's a live lock, as if I insert a USB drive, 
I

get the da0 messages.

Keyboard num lock light will change state, and ctrl/T shows NOTHING.


Can you break into DDB with Ctrl-Alt-Backspace and get the output of
'ps'?

I was NOT able to get to ddb.  I did send jhb@ a pic of the console.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: boot with floppy enabled doesn't.....

2016-05-02 Thread Larry Rosenman

On 2016-05-02 13:29, John Baldwin wrote:

On Monday, May 02, 2016 12:54:32 PM Larry Rosenman wrote:

On 2016-05-02 12:27, Larry Rosenman wrote:
> On 2016-05-02 11:57, John Baldwin wrote:
>> On Saturday, April 30, 2016 10:36:53 PM Larry Rosenman wrote:
>>> On a current -CURRENT if my Floppy disk controller and device are
>>> ENABLED, we do NOT pass mount root, and the floppy disk
>>> light is ON.
>>>
>>> If I disable the floppy controller/drive in the BIOS, we boot.
>>>
>>> This started after April 18.
>>>
>>> I'm not sure what info to gather.
>>
>> I recently changed some things in the fdc(4) driver that are the
>> first suspect.  You are stuck at the mountroot prompt?  Is your
>> root filesystem on the floppy or on something else?
> The system does mount root, but never gets to the RC Scripts.  Root is
> on ZFS, and NOTHING is in the floppy drive.
Oh, and it seems(!) like it's a live lock, as if I insert a USB drive, 
I

get the da0 messages.

Keyboard num lock light will change state, and ctrl/T shows NOTHING.


Can you break into DDB with Ctrl-Alt-Backspace and get the output of
'ps'?

I'll try tonight when I'm home in front of the box.

I'll send pictures :)

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: boot with floppy enabled doesn't.....

2016-05-02 Thread Larry Rosenman

On 2016-05-02 12:27, Larry Rosenman wrote:

On 2016-05-02 11:57, John Baldwin wrote:

On Saturday, April 30, 2016 10:36:53 PM Larry Rosenman wrote:

On a current -CURRENT if my Floppy disk controller and device are
ENABLED, we do NOT pass mount root, and the floppy disk
light is ON.

If I disable the floppy controller/drive in the BIOS, we boot.

This started after April 18.

I'm not sure what info to gather.


I recently changed some things in the fdc(4) driver that are the
first suspect.  You are stuck at the mountroot prompt?  Is your
root filesystem on the floppy or on something else?

The system does mount root, but never gets to the RC Scripts.  Root is
on ZFS, and NOTHING is in the floppy drive.
Oh, and it seems(!) like it's a live lock, as if I insert a USB drive, I 
get the da0 messages.


Keyboard num lock light will change state, and ctrl/T shows NOTHING.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: boot with floppy enabled doesn't.....

2016-05-02 Thread Larry Rosenman

On 2016-05-02 11:57, John Baldwin wrote:

On Saturday, April 30, 2016 10:36:53 PM Larry Rosenman wrote:

On a current -CURRENT if my Floppy disk controller and device are
ENABLED, we do NOT pass mount root, and the floppy disk
light is ON.

If I disable the floppy controller/drive in the BIOS, we boot.

This started after April 18.

I'm not sure what info to gather.


I recently changed some things in the fdc(4) driver that are the
first suspect.  You are stuck at the mountroot prompt?  Is your
root filesystem on the floppy or on something else?

The system does mount root, but never gets to the RC Scripts.  Root is
on ZFS, and NOTHING is in the floppy drive.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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"


boot with floppy enabled doesn't.....

2016-04-30 Thread Larry Rosenman
On a current -CURRENT if my Floppy disk controller and device are 
ENABLED, we do NOT pass mount root, and the floppy disk

light is ON.

If I disable the floppy controller/drive in the BIOS, we boot.

This started after April 18.

I'm not sure what info to gather.



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: extremely slow to get to loader

2016-04-24 Thread Larry Rosenman

On 2016-04-21 20:56, Johannes Dieterich wrote:
On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude <allanj...@freebsd.org> 
wrote:

On 2016-04-21 10:46, Johannes Dieterich wrote:

Dear all,

with r298385, I observe extremely long times from turning on my 
laptop
to reach loader. This is a regression compared to a roughly 1 week 
old

CURRENT.

This is an AMD A12-8800B laptop booting in legacy mode into a 
ZFS+GELI setup.


Please let me know how I can help to solve this issue.

Thanks,

Johannes
___
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"




Can you describe where exactly it is slow?

Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes
before it eventually continues.


Once you get to the loader menu (the beastie menu), can you choose the
option to go to the loader prompt, and type:
bcachestat

And provide the output of that.

Here we go (w/o mistakes I hope...):
cache blocks: 32768
cache blocksz: 572
unit cache blocks: 32768
cached units: 1
1162 ops 0 bypasses 12109 hits 739 misses

Thanks so much for the response!

Johannes
I'm seeing similar, PLUS the kernel seems(!) to not continue on to the 
RC scripts

after mount root.

(BIOS BOOT).

I reverted to an older kernel and boot block and zfsloader to get up.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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: xo_config.h missing?

2016-03-19 Thread Larry Rosenman
On Wed, Mar 16, 2016 at 08:28:26PM -0500, Larry Rosenman wrote:
> ll_subdir_usr.bin/xo ---
> /usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not 
> found
> #include "xo_config.h"
> 
> 
> 
> Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 296976
> Node Kind: directory
> Schedule: normal
> Last Changed Author: np
> Last Changed Rev: 296975
> Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)
> 

more info:
(cd /usr/src/lib/libxo/tests &&  DEPENDFILE=.depend.test_05  NO_SUBDIR=1 
/usr/obj/usr/src/make.amd64/bmake -f /usr/src/lib/libxo/tests/Makefile 
_RECURSING_PROGS=t  PROG=test_05 )
echo test_05.full: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libxo.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> 
.depend.test_05
cc  -O2 -pipe   -I/usr/src/contrib/libxo/libxo -g -MD  
-MF.depend.test_05.test_05.o -MTtest_05.o -std=gnu99 -fstack-protector-strong   
 -Qunused-arguments -c /usr/src/contrib/libxo/tests/core/test_05.c -o test_05.o
/usr/src/contrib/libxo/tests/core/test_05.c:17:10: fatal error: 'xo_config.h' 
file not found
#include "xo_config.h"
 ^
1 error generated.
*** Error code 1

Stop.
bmake[6]: stopped in /usr/src/lib/libxo/tests
*** Error code 1

Stop.
bmake[5]: stopped in /usr/src/lib/libxo/tests
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/lib/libxo
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src/lib
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

Stop.
bmake[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
^C
[1]   Done(1)     nohup make -DNO_CLEAN buildworld buildkernel 
>>make.cont.out 2>&1
# 

> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640     E-Mail: l...@lerctr.org
> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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"


xo_config.h missing?

2016-03-19 Thread Larry Rosenman
ll_subdir_usr.bin/xo ---
/usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not found
#include "xo_config.h"



Path: /usr/src
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 296976
Node Kind: directory
Schedule: normal
Last Changed Author: np
Last Changed Rev: 296975
Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: Crashes in libthr?

2016-03-15 Thread Larry Rosenman

On 2016-03-15 12:21, Larry Rosenman wrote:

This may have been my screw up


On March 15, 2016 12:05:03 PM Bryan Drewery <bdrew...@freebsd.org> 
wrote:



On 3/14/16 8:03 PM, Larry Rosenman wrote:

On 2016-03-14 21:49, Larry Rosenman wrote:

On 2016-03-14 18:49, Larry Rosenman wrote:

On 2016-03-14 18:47, Steven Hartland wrote:

On 14/03/2016 22:28, Larry Rosenman wrote:

On 2016-03-14 17:25, Poul-Henning Kamp wrote:


In message <2016031428.ga1...@borg.lerctr.org>, Larry 
Rosenman

writes:


And sshd is busted.


FYI: I seeing no such issues on two systems running:

11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016
and
11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016

As I said it's this ONE box, even doing an install from the other
(RUNNING) boxes
/usr/src,/usr/obj).

This build was at:
borg.lerctr.org /usr/src $ svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 296823
Node Kind: directory
Schedule: normal
Last Changed Author: adrian
Last Changed Rev: 296823
Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016)

borg.lerctr.org /usr/src $


I can post the make.conf.

It's really weird.

Silly question your not building on an NFS FS are you?




No, this is local disk.  The "install from other machine" was via
NFS..



I found it.  A bad version (from march 8th or so) of
/lib/libprivatessh.so.5 that did NOT export the symbol, but the
version in /usr/lib/libprivatessh.so.5 DID export the symbol.

I wiped out the /lib/libprivate* and re-did installworld.

and all seems fine now.

I suspect I hit a time when the tree had bad stuff installing into
/lib/libprivate*



BTW, there were LOTS of OTHER things in /lib with the same bad date,
which I've now cleaned up.

make delete-old{-libs} did *NOT* clean this up.




These were dated March 8 2016?  I don't recall any recent changes
causing libraries to be installed to the wrong place.

--
Regards,
Bryan Drewery

I think I screwed up badly..

So, thank G-D for ZFS snapshots and Boot Environments.  I've reverted to 
an earler snap/root via

clone/promote.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: Crashes in libthr?

2016-03-15 Thread Larry Rosenman

This may have been my screw up


On March 15, 2016 12:05:03 PM Bryan Drewery <bdrew...@freebsd.org> wrote:


On 3/14/16 8:03 PM, Larry Rosenman wrote:

On 2016-03-14 21:49, Larry Rosenman wrote:

On 2016-03-14 18:49, Larry Rosenman wrote:

On 2016-03-14 18:47, Steven Hartland wrote:

On 14/03/2016 22:28, Larry Rosenman wrote:

On 2016-03-14 17:25, Poul-Henning Kamp wrote:


In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman
writes:


And sshd is busted.


FYI: I seeing no such issues on two systems running:

11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016
and
11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016

As I said it's this ONE box, even doing an install from the other
(RUNNING) boxes
/usr/src,/usr/obj).

This build was at:
borg.lerctr.org /usr/src $ svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 296823
Node Kind: directory
Schedule: normal
Last Changed Author: adrian
Last Changed Rev: 296823
Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016)

borg.lerctr.org /usr/src $


I can post the make.conf.

It's really weird.

Silly question your not building on an NFS FS are you?




No, this is local disk.  The "install from other machine" was via
NFS..



I found it.  A bad version (from march 8th or so) of
/lib/libprivatessh.so.5 that did NOT export the symbol, but the
version in /usr/lib/libprivatessh.so.5 DID export the symbol.

I wiped out the /lib/libprivate* and re-did installworld.

and all seems fine now.

I suspect I hit a time when the tree had bad stuff installing into
/lib/libprivate*



BTW, there were LOTS of OTHER things in /lib with the same bad date,
which I've now cleaned up.

make delete-old{-libs} did *NOT* clean this up.




These were dated March 8 2016?  I don't recall any recent changes
causing libraries to be installed to the wrong place.

--
Regards,
Bryan Drewery



___
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: Crashes in libthr?

2016-03-14 Thread Larry Rosenman

On 2016-03-14 21:49, Larry Rosenman wrote:

On 2016-03-14 18:49, Larry Rosenman wrote:

On 2016-03-14 18:47, Steven Hartland wrote:

On 14/03/2016 22:28, Larry Rosenman wrote:

On 2016-03-14 17:25, Poul-Henning Kamp wrote:


In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman 
writes:



And sshd is busted.


FYI: I seeing no such issues on two systems running:

11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016
and
11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016
As I said it's this ONE box, even doing an install from the other 
(RUNNING) boxes

/usr/src,/usr/obj).

This build was at:
borg.lerctr.org /usr/src $ svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 296823
Node Kind: directory
Schedule: normal
Last Changed Author: adrian
Last Changed Rev: 296823
Last Changed Date: 2016-03-13 23:39:35 -0500 (Sun, 13 Mar 2016)

borg.lerctr.org /usr/src $


I can post the make.conf.

It's really weird.

Silly question your not building on an NFS FS are 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"
No, this is local disk.  The "install from other machine" was via 
NFS..



I found it.  A bad version (from march 8th or so) of
/lib/libprivatessh.so.5 that did NOT export the symbol, but the
version in /usr/lib/libprivatessh.so.5 DID export the symbol.

I wiped out the /lib/libprivate* and re-did installworld.

and all seems fine now.

I suspect I hit a time when the tree had bad stuff installing into
/lib/libprivate*



BTW, there were LOTS of OTHER things in /lib with the same bad date, 
which I've now cleaned up.


make delete-old{-libs} did *NOT* clean this up.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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"


  1   2   3   4   >