Re: what do jails map 127.0.0.1 to?

2019-02-10 Thread Alan Somers
On Sun, Feb 10, 2019 at 5:51 PM Rick Macklem wrote: > > I am finally back to looking at an old PR#205193. > > The problem is that the nfsuserd daemon expects upcalls from the kernel > that are from localhost (127.0.0.1) and when jails are running on the system, > 127.0.0.1 is mapped to some other

what do jails map 127.0.0.1 to?

2019-02-10 Thread Rick Macklem
I am finally back to looking at an old PR#205193. The problem is that the nfsuserd daemon expects upcalls from the kernel that are from localhost (127.0.0.1) and when jails are running on the system, 127.0.0.1 is mapped to some other IP#. (I think it might be the address of the first net interface

Re: 13.0-CURRENT oddity in output of dialog(1)

2019-02-10 Thread Alan Somers
On Sun, Feb 10, 2019 at 2:27 PM David Boyd wrote: > > In 13.0-CURRENT, dialog(1) fills lines shorter than the box width with > something other than the background color. In an xterm session, the > fill is white. In a console session, the fill is black. > > This appears to be a regression in the d

13.0-CURRENT oddity in output of dialog(1)

2019-02-10 Thread David Boyd
In 13.0-CURRENT, dialog(1) fills lines shorter than the box width with something other than the background color. In an xterm session, the fill is white. In a console session, the fill is black. This appears to be a regression in the dialog(1) utility not seen in previous (11.2-RELEASE and 12.0-

Re: "Oddness" in head since around r343678 or so

2019-02-10 Thread Niclas Zeising
On 2019-02-10 16:35, Niclas Zeising wrote: On 2019-02-08 10:27, Alexander Leidinger wrote: Hi, I recently noticed some generic slowness myself. I experienced this during replacing disks in a raidz by bigger ones. Long story short, check top -s if you have vnlru running for a long period at hi

Re: "Oddness" in head since around r343678 or so

2019-02-10 Thread Niclas Zeising
On 2019-02-08 10:27, Alexander Leidinger wrote: Hi, I recently noticed some generic slowness myself. I experienced this during replacing disks in a raidz by bigger ones. Long story short, check top -s if you have vnlru running for a long period at high CPU... If yes increase kern.maxvnodes (I

64-bit integer overflow computing user CPU time in calcru1() in kern_resource.c

2019-02-10 Thread sthaug
There is a 64-bit integer overflow computing user cpu time in calcru1() in kern_resource.c. This was discovered because CPU statistics from the PowerDNS-recursor name server stopped working (essentially, got "stuck") after a while: time_t milliseconds 1547818832 301274008.418503 1547