Re: TSC timekeeping and cpu states

On Mon, Aug 14, 2017 at 8:38 AM, Ian Smith wrote: > On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote: > > > On 14/8/17 3:08PM, Kevin Oberman wrote: > > > Again, the documentation lags reality. The default was changed for > > > 11.0. It is still conservative.

Re: TSC timekeeping and cpu states

On 14.08.2017 18:38, Ian Smith wrote: > On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote: > > On 14/8/17 3:08PM, Kevin Oberman wrote: > > > Again, the documentation lags reality. The default was changed for > > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield

Re: TSC timekeeping and cpu states

On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote: > On 14/8/17 3:08PM, Kevin Oberman wrote: > > Again, the documentation lags reality. The default was changed for > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield > > the bast results. However, on large

Re: Error in /usr/src/release/release.sh

On Mon, Aug 14, 2017 at 09:12:04AM -0600, Ian Lepore wrote: > On Mon, 2017-08-14 at 14:34 +, Glen Barber wrote: > > On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote: > > > > > > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote: > > > > > > > > On Mon, Aug 14, 2017 at 01:18:14PM

Re: Error in /usr/src/release/release.sh

On Mon, 2017-08-14 at 14:34 +, Glen Barber wrote: > On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote: > > > > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote: > > > > > > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote: > > > > > > > > > > > > On Sat, Aug 12,

Re: Error in /usr/src/release/release.sh

On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote: > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote: > > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote: > > > > > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote: > > > > > > > > When trying to build a

Re: Error in /usr/src/release/release.sh

On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote: > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote: > > > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote: > > > > > > When trying to build a set of RELENG/11.1 release files, I'm > > > getting the > > > following

Re: Error in /usr/src/release/release.sh

On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote: > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote: > > When trying to build a set of RELENG/11.1 release files, I'm getting the > > following error (tail end of output) in the release.sh run: > >

Re: Error in /usr/src/release/release.sh

On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote: > When trying to build a set of RELENG/11.1 release files, I'm getting the > following error (tail end of output) in the release.sh run: > -- > >>> Kernel build for ALLWINNER

Re: nullfs making contents of ZFS datasets invisible even after unmounting

With a little bit of help, I managed to figure out what the problem was. It turned out that I had run, head first, into the wall of nullfs not operating across file systems. Thus inside the jail, the data was being saved to a regular directory on my "storage/cloud"-dataset (Mountpoint:

Re: zfs listing and CPU

Interesting, even the illumos man page doesn't have the -c defined. I remember reading about it at one point. I can only get `zfs get -Hrpc all` working, even though -c is not documented. So, I retract my statement on the zfs list with cached. # zfs get -*Hpc* -o property,value name,used,avail

nullfs making contents of ZFS datasets invisible even after unmounting

I am running a FreeBSD 11.1 system with ZFS and jails and I mount a file system on my storage pool (/storage/cloud) into the jail (/jails/cloud/storage) via nullfs, and that works fine for what the jail does. However I just noticed that outside the jail, I can only see the mount points of the file

Re: TSC timekeeping and cpu states

On 14/8/17 3:08PM, Kevin Oberman wrote: > Again, the documentation lags reality. The default was changed for 11.0. It > is still conservative. In ALMOST all cases, Cmax will yield the bast results. > However, on large systems with many cores, Cmax will trigger very poor > results, so the