Re: struct timehands: th_generation field

2015-07-23 Thread Brandon Allbery 
On Thu, Jul 23, 2015 at 9:43 AM,  wrote:

> I am struggling on one field of a struct :
> http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L63
> I would like to understand what th_generation means please.
>

Seems to me you get a clue from: (
http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L192)

*/*** * Functions for reading the time.  We have to loop until we are
sure that** * the timehands that we operated on was not updated under
our feet.  See** * the comment in  for a description of
these 12 functions.** */*
>
> #ifdef FFCLOCK
> voidfbclock_binuptime 
> (struct 
> bintime  *bt 
> )
> {
> struct timehands 
>  *th;
> unsigned int gen ;
>
> do {
> th = timehands 
> ;
> gen  = 
> th->th_generation;
> *bt  = 
> th->th_offset;
> bintime_addx 
> (bt 
> , th->th_scale * tc_delta 
> (th));
> } while (gen  == 0 
> || gen  != 
> th->th_generation);
> }
>
> --
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Heads-up: Change to 10.2-RELEASE schedule

2015-07-23 Thread Glen Barber 
At this time, re@ feels it is not necessary to have 10.2-BETA3 as part
of the release cycle, so the next 10.2 builds (planned to start in just
under 9 hours) will be 10.2-RC1.

The 10.2-RELEASE schedule has been updated on the FreeBSD.org website to
reflect this change, and is also included in this email.

https://www.FreeBSD.org/releases/10.2R/schedule.html

 releng/10.2 branch:  July 24, 2015
 RC1 build starts:July 24, 2015
 stable/10 thaw:  July 26, 2015
 ports package builds:July 27, 2015
 RC2 build starts:July 31, 2015
 RC3 build starts:August 7, 2015 [*]
 RELEASE build starts:August 21, 2015
 RELEASE announcement:August 31, 2015
 [*]  - If needed

Note, the final 10.2-RELEASE build and announcement dates have been
unchanged to account for any delays for the remainder of the release
cycle.  These dates will be updated as necessary as the release cycle
progresses.

Thank you.

Glen
On behalf of:   re@



pgpEGEWrccNI4.pgp
Description: PGP signature

struct timehands: th_generation field

2015-07-23 Thread deco33000 
Hi,

Currently I read more about timers and clock.

I am struggling on one field of a struct : 
http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L63

I would like to understand what th_generation means please.

Thanks a lot

-- 
Jog
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: struct timehands: th_generation field

2015-07-23 Thread Brandon Allbery 
On Thu, Jul 23, 2015 at 10:38 AM,  wrote:

> Is the maximum value for th_generation equal to 10 ?
> http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L77
>

I don't think those relate to generations. Generations change on every
clock tick; the multiple timehands structs relate to forcibly setting the
time, as opposed to the clock moving forward normally. It does appear serve
a similar purpose, since forcibly setting the time is even more "violent"
(to anything currently reading the clock) than advancing the clock on a
clock tick, since that's when other adjustments including possibly
switching the clock source will be applied.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: struct timehands: th_generation field

2015-07-23 Thread Ian Lepore 
On Thu, 2015-07-23 at 10:59 -0400, Brandon Allbery wrote:
> On Thu, Jul 23, 2015 at 10:38 AM,  wrote:
> 
> > Is the maximum value for th_generation equal to 10 ?
> > http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L77
> >
> 
> I don't think those relate to generations. Generations change on every
> clock tick; the multiple timehands structs relate to forcibly setting the
> time, as opposed to the clock moving forward normally. It does appear serve
> a similar purpose, since forcibly setting the time is even more "violent"
> (to anything currently reading the clock) than advancing the clock on a
> clock tick, since that's when other adjustments including possibly
> switching the clock source will be applied.
> 

Ummm, no.  The multiple timehands and related generation count are all
about time moving forward normally, and doing so without needing mutxes
or other locking primitives to obtain the current time.  I think you
guys need to read this...

  http://phk.freebsd.dk/pubs/timecounter.pdf

Especially the section named "Locking, lack of..."

-- Ian


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: struct timehands: th_generation field

2015-07-23 Thread deco33000 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Jason Unovitch 

>> ..uh top quoting..
>>
>> Trying to mount root from zfs:zroot/ROOT/default [].
>>
>> Fatal double fault:
>> eip = 0xc0b416f5
>> esp = 0xe2673000
>> ebp = 0xe2673008
>> cpuid =0; apic id = 00
>> panic: double fault
>> cpuid = 0
>> KDB stack backtrace:
>> #0 0xc0b72832 at kdb_backtrace+0x52
>> #1 0xc0b339cb at vpanic+0x11b
>> #2 0xc0b338ab at panic+0x1b
>> #3 0xc10556 at dblfault_handler+0xab
>> Uptime: 11s
>> ..
>
>Looks like the panic I received on my Soekris Net6501-70.
>
>Fixed in stable/10 in r285759:
>https://svnweb.freebsd.org/changeset/base/285759
>
>Fixed in stable/9 in r285760:
>https://svnweb.freebsd.org/changeset/base/285760
>
>--
>Herbert

Herbert, in https://bugs.FreeBSD.org/201642 I had tracked down the 
commit that caused the issue on our Soekris 6501s.  Only between r284297 
-> r285662 in HEAD and between r284998 -> r285756 in stable/10 should be 
affected.


>>>Ok, it is 10.2-BETA so I've tried 10.1-Release next...exactly the same,
>>>ok tried 9.3-RELEASE .. the same!

Holm, if you are seeing this on 9.3-RELEASE and 10.1-RELEASE I'm not 
entirely convinced the cause is the same.


--
Jason
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Glen Barber 
On Thu, Jul 23, 2015 at 07:40:42PM -0400, Jason Unovitch wrote:
> >> ..uh top quoting..
> >>
> >> Trying to mount root from zfs:zroot/ROOT/default [].
> >>
> >> Fatal double fault:
> >> eip = 0xc0b416f5
> >> esp = 0xe2673000
> >> ebp = 0xe2673008
> >> cpuid =0; apic id = 00
> >> panic: double fault
> >> cpuid = 0
> >> KDB stack backtrace:
> >> #0 0xc0b72832 at kdb_backtrace+0x52
> >> #1 0xc0b339cb at vpanic+0x11b
> >> #2 0xc0b338ab at panic+0x1b
> >> #3 0xc10556 at dblfault_handler+0xab
> >> Uptime: 11s
> >> ..
> >
> >Looks like the panic I received on my Soekris Net6501-70.
> >
> >Fixed in stable/10 in r285759:
> >https://svnweb.freebsd.org/changeset/base/285759
> >
> >Fixed in stable/9 in r285760:
> >https://svnweb.freebsd.org/changeset/base/285760
> >
> 
> Herbert, in https://bugs.FreeBSD.org/201642 I had tracked down the commit
> that caused the issue on our Soekris 6501s.  Only between r284297 -> r285662
> in HEAD and between r284998 -> r285756 in stable/10 should be affected.
> 
> >>>Ok, it is 10.2-BETA so I've tried 10.1-Release next...exactly the same,
> >>>ok tried 9.3-RELEASE .. the same!
> 
> Holm, if you are seeing this on 9.3-RELEASE and 10.1-RELEASE I'm not
> entirely convinced the cause is the same.
> 

ZFS on i386 requires KSTACK_PAGES=4 in the kernel configuration to work
properly, as noted in the 10.1-RELEASE errata (and release notes, if
I remember correctly).

We cannot set KSTACK_PAGES=4 in GENERIC by default, as it is too
disruptive.  If you are using ZFS on i386, you *must* build your own
kernel for this.  It is otherwise unsupported by default.

Glen



pgpx2cp89PFDy.pgp
Description: PGP signature

Re: freebsd downgrade

2015-07-23 Thread Xin Li 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/23/15 16:21, Stari Karp wrote:
> Hi!
> 
> I had a problems with FreeBSD 10.2-BETA2. I used freebsd-update
> ugrade and update FreeBSD 10.1-RELEASE. Is it possible to downgrade
> BETA2 to 10.1-RELEASE with freebsd-update upgrade -r 10.1-RELEASE,
> please?

It's not supported (because you may be running binaries that depends
on new kernel).

What kind of problems did you have?  Please let re@ know so we can get
them fixed.

Cheers,
- -- 
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVsX3rAAoJEJW2GBstM+nshTsP/1gkFDhlrzElnOPfxtQEc80H
6oocZG4Upn9UbrFIq9GKU4qU8XIC8fHtYtLyXAbjj5vebEMkOAJuhzE8HrN3eh+N
hZKtKRiK7fNSFWCkqmd2BY0G05IBEXgQXzbgRzc65OrRcrp5MSL109bxYjN7Ih1L
wMtulWxfxyqsCZ4h6qwjZehJTkPMwiaGfhjbxAUbghzJKEyCKVGmGCE5Wbz4q++W
9bkQXElu1777WlJ3X+6tvgRkBxpYdaXSzL2UAH5cZrM7b5T09KfcgKsl+x9o1CGN
PGRQZqNcdyxEebjMqJaE2BOuvtocIrlpEOtC0VT7f5pLp64pV8PYPQGzdi+01LZD
w/wNvkJFqhIT42h/DDuTj7kOsrJhDA5Q2Vho9KW4YZFbDO9eglCA2KhDgrLQejl3
9z0byDWq+my638CRQIjHcf0QBokdXceK/AVjnIx9Os59OD0dQkl3ISSRhSDQPmqe
urI96uQ582vo6h+Tiic119aPtmy7aTn6PqtsTEYLnb5YTFx8oF4XaBuP7a3RmcBm
JX3oX5vIzOiDWtnG27yhsy5Bido91xPznnCLoC24MKuO7YFJb9Pi4x4fy8jIQkpp
gZTz7AkGR8oFroisPb9DGkkhT5QcwQviEnyRA1pR0dk7Sv6mzckRRSxxMn6s1SrY
0oVGHIe54nF7T1MRZc15
=BS7Y
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Chris H 
On Thu, 23 Jul 2015 23:48:06 + Glen Barber  wrote

> On Thu, Jul 23, 2015 at 07:40:42PM -0400, Jason Unovitch wrote:
> > >> ..uh top quoting..
> > >>
> > >> Trying to mount root from zfs:zroot/ROOT/default [].
> > >>
> > >> Fatal double fault:
> > >> eip = 0xc0b416f5
> > >> esp = 0xe2673000
> > >> ebp = 0xe2673008
> > >> cpuid =0; apic id = 00
> > >> panic: double fault
> > >> cpuid = 0
> > >> KDB stack backtrace:
> > >> #0 0xc0b72832 at kdb_backtrace+0x52
> > >> #1 0xc0b339cb at vpanic+0x11b
> > >> #2 0xc0b338ab at panic+0x1b
> > >> #3 0xc10556 at dblfault_handler+0xab
> > >> Uptime: 11s
> > >> ..
> > >
> > >Looks like the panic I received on my Soekris Net6501-70.
> > >
> > >Fixed in stable/10 in r285759:
> > >https://svnweb.freebsd.org/changeset/base/285759
> > >
> > >Fixed in stable/9 in r285760:
> > >https://svnweb.freebsd.org/changeset/base/285760
> > >
> > 
> > Herbert, in https://bugs.FreeBSD.org/201642 I had tracked down the commit
> > that caused the issue on our Soekris 6501s.  Only between r284297 ->
> > r285662 in HEAD and between r284998 -> r285756 in stable/10 should be
> > affected. 
> > >>>Ok, it is 10.2-BETA so I've tried 10.1-Release next...exactly the same,
> > >>>ok tried 9.3-RELEASE .. the same!
> > 
> > Holm, if you are seeing this on 9.3-RELEASE and 10.1-RELEASE I'm not
> > entirely convinced the cause is the same.
> > 
> 
> ZFS on i386 requires KSTACK_PAGES=4 in the kernel configuration to work
> properly, as noted in the 10.1-RELEASE errata (and release notes, if
> I remember correctly).
> 
> We cannot set KSTACK_PAGES=4 in GENERIC by default, as it is too
> disruptive.  If you are using ZFS on i386, you *must* build your own
> kernel for this.  It is otherwise unsupported by default.
Shouldn't there be a GENERIC kernel with the KSTACK_PAGES=4 option
defined, available? Maybe with one of the bootonly MEMSTICKS, or
something? I know, it's (mostly) crazy to attempt ZFS on an i386. But
it's pretty difficult for someone on 8.x to build a 9.x, or 10.x kernel.
If all they've got is i386 hardware.

Just a thought.

--Chris
> 
> Glen


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Michelle Sullivan 
Glen Barber wrote:
>
> ZFS on i386 requires KSTACK_PAGES=4 in the kernel configuration to work
> properly, as noted in the 10.1-RELEASE errata (and release notes, if
> I remember correctly).
>
> We cannot set KSTACK_PAGES=4 in GENERIC by default, as it is too
> disruptive.  

Why?

> If you are using ZFS on i386, you *must* build your own
> kernel for this.  It is otherwise unsupported by default.
>   
Why is zfs on i386 so hard?  Why is it even in the GENERIC kernel if
it's unsupported?


-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

freebsd downgrade

2015-07-23 Thread Stari Karp 
Hi!

I had a problems with FreeBSD 10.2-BETA2. I used freebsd-update ugrade
and update FreeBSD 10.1-RELEASE.
Is it possible to downgrade BETA2 to 10.1-RELEASE with freebsd-update
upgrade -r 10.1-RELEASE, please?

Thank you.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Glen Barber 
On Fri, Jul 24, 2015 at 02:19:20AM +0200, Michelle Sullivan wrote:
> Glen Barber wrote:
> >
> > ZFS on i386 requires KSTACK_PAGES=4 in the kernel configuration to work
> > properly, as noted in the 10.1-RELEASE errata (and release notes, if
> > I remember correctly).
> >
> > We cannot set KSTACK_PAGES=4 in GENERIC by default, as it is too
> > disruptive.  
> 
> Why?
> 

Because it takes resources away from userland threads.

> > If you are using ZFS on i386, you *must* build your own
> > kernel for this.  It is otherwise unsupported by default.
> >   
> Why is zfs on i386 so hard?  Why is it even in the GENERIC kernel if
> it's unsupported?
> 

It is not in GENERIC by default.  You have to specifically kldload(8)
zfs.ko.

Glen



pgpBXn0STiajy.pgp
Description: PGP signature

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Mark Linimon 
On Fri, Jul 24, 2015 at 02:19:20AM +0200, Michelle Sullivan wrote:
> Why is zfs on i386 so hard?

zfs is a resource hog.  i386 is not able to handle the demand as well
as amd64.

I have never, ever, heard of anyone who has a deep understanding of
zfs on FreeBSD recommend anything other than amd64.  (Note: I am not
such a person, so I am simply reporting my understanding.)

FWIW, I tried it once.

Once.

After spending a few days inspecting all the bullet holes in my feet,
I moved it off that i386 machine and all the bullet holes healed up.

tl;dr: zfs/i386 Not Recommended.  But YMMV.

mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Brandon Allbery 
On Thu, Jul 23, 2015 at 8:40 PM, Mark Linimon  wrote:

> zfs is a resource hog.  i386 is not able to handle the demand as well
> as amd64.
>

Even amd64 is no guarantee. I installed one of the Illumos spinoffs on a
2GB amd64 netbook (they mostly force zfs). I think it lasted 2 days before
the kernel panics started.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Mark Linimon 
On Fri, Jul 24, 2015 at 12:43:43AM +, Glen Barber wrote:
> Even on amd64, you need to tune the system with less than 4GB RAM.

The only correct answer to "how much RAM do you need to run ZFS" is
"always more" AFAICT.

mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Glen Barber 
On Thu, Jul 23, 2015 at 08:42:44PM -0400, Brandon Allbery wrote:
> On Thu, Jul 23, 2015 at 8:40 PM, Mark Linimon  wrote:
> 
> > zfs is a resource hog.  i386 is not able to handle the demand as well
> > as amd64.
> >
> 
> Even amd64 is no guarantee. I installed one of the Illumos spinoffs on a
> 2GB amd64 netbook (they mostly force zfs). I think it lasted 2 days before
> the kernel panics started.
> 

Even on amd64, you need to tune the system with less than 4GB RAM.

Glen



pgpoZDAUBEQMT.pgp
Description: PGP signature

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Brandon Allbery 
On Thu, Jul 23, 2015 at 8:43 PM, Glen Barber  wrote:

> > Even amd64 is no guarantee. I installed one of the Illumos spinoffs on a
> > 2GB amd64 netbook (they mostly force zfs). I think it lasted 2 days
> before
> > the kernel panics started.
> >
>
> Even on amd64, you need to tune the system with less than 4GB RAM.


I knew it wasn't going to fly, in fact I looked for ways to get the
installer to do ufs instead because I couldn't imagine zfs being able to
work in 2GB. Somehow I don't think old netbooks are in Illumos's plans. :)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Glen Barber 
On Thu, Jul 23, 2015 at 07:44:43PM -0500, Mark Linimon wrote:
> On Fri, Jul 24, 2015 at 12:43:43AM +, Glen Barber wrote:
> > Even on amd64, you need to tune the system with less than 4GB RAM.
> 
> The only correct answer to "how much RAM do you need to run ZFS" is
> "always more" AFAICT.
> 

There's a bit more to it than that.  You *can* successfully run amd64
ZFS system with certain tunings (vfs.kmem_max IIRC), but you also need
to adjust things like disabling prefetching with less than 4GB RAM
(accessible to the OS).

So yeah, "more RAM" is always a thing in this playing field.

Glen



pgplAqYMvbWtY.pgp
Description: PGP signature

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Michelle Sullivan 
Glen Barber wrote:
> On Thu, Jul 23, 2015 at 07:44:43PM -0500, Mark Linimon wrote:
>   
>> On Fri, Jul 24, 2015 at 12:43:43AM +, Glen Barber wrote:
>> 
>>> Even on amd64, you need to tune the system with less than 4GB RAM.
>>>   
>> The only correct answer to "how much RAM do you need to run ZFS" is
>> "always more" AFAICT.
>>
>> 
>
> There's a bit more to it than that.  You *can* successfully run amd64
> ZFS system with certain tunings (vfs.kmem_max IIRC), but you also need
> to adjust things like disabling prefetching with less than 4GB RAM
> (accessible to the OS).
>
> So yeah, "more RAM" is always a thing in this playing field.
>
> Glen
>
>   
Actually I'm quite sucessfully running zfs on i386 (in a VM) ... here's
the trick (which leads me to suspect ARC handling as the problem) - when
I get to 512M of kernel space or less than 1G of RAM available system
wide, I export/import the zfs pool...  Using this formula I have uptimes
of months... I haven't yet tried the 'ARC patch' that was proposed
recently...


-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Glen Barber 
On Fri, Jul 24, 2015 at 02:54:00AM +0200, Michelle Sullivan wrote:
> Glen Barber wrote:
> > On Thu, Jul 23, 2015 at 07:44:43PM -0500, Mark Linimon wrote:
> >   
> >> On Fri, Jul 24, 2015 at 12:43:43AM +, Glen Barber wrote:
> >> 
> >>> Even on amd64, you need to tune the system with less than 4GB RAM.
> >>>   
> >> The only correct answer to "how much RAM do you need to run ZFS" is
> >> "always more" AFAICT.
> >>
> >> 
> >
> > There's a bit more to it than that.  You *can* successfully run amd64
> > ZFS system with certain tunings (vfs.kmem_max IIRC), but you also need
> > to adjust things like disabling prefetching with less than 4GB RAM
> > (accessible to the OS).
> >
> > So yeah, "more RAM" is always a thing in this playing field.
> >
> > Glen
> >
> >   
> Actually I'm quite sucessfully running zfs on i386 (in a VM) ... here's
> the trick (which leads me to suspect ARC handling as the problem) - when
> I get to 512M of kernel space or less than 1G of RAM available system
> wide, I export/import the zfs pool...  Using this formula I have uptimes
> of months... I haven't yet tried the 'ARC patch' that was proposed
> recently...
> 

Which FreeBSD version is this?  Things changed since 10.1-RELEASE and
what will be 10.2-RELEASE enough that I can't even get a single-disk ZFS
system (in VirtualBox) to boot on i386.  During 10.1-RELEASE testing,
I only saw problems with multi-disk setup (mirror, raidzN), but the
FreeBSD kernel grew since 10.1-RELEASE, so this is not unexpected.

Glen



pgpLlYB_ift8p.pgp
Description: PGP signature

Re: 10.2-Beta i386..what's wrong..?

2015-07-23 Thread Chris H 
On Fri, 24 Jul 2015 01:00:03 + Glen Barber  wrote
..
> FreeBSD kernel grew since 10.1-RELEASE, so this is not unexpected.
Not trying to hijack the thread, or anything.
But on that note; does FreeBSD keep a graph, or anything that indicates
kernel [size] over major versions?

I'm sure I'm not the only one that would find this interesting. :)

--Chris
> 
> Glen


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

10.2-BETA2 patch etc/ntp.conf to enable ntpd pool client functionality

2015-07-23 Thread John Marshall 
I have submitted a patch to the distributed ntp.conf to enable ntpd pool
client functionality.  This was not possible in the ancient version of
ntpd shipped with FreeBSD releases over the past several years.

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

Essentially this gives you a larger set of DYNAMIC servers from the
pool.  If ntpd decides one of the configured servers has become
unreliable it will drop it and configure a new one.

Also, there is a 'restrict source' command which provides template
access restrictions for upstream servers.  When a server is dynamically
configured, a dynamic restrict entry is created for it from the
'restrict source' template.  When a server is dynamically removed, its
'restrict' entry is also removed.

This is the result on a 10.2-BETA2 (r285783) server.

rwsrv02> ntpq -np
 remote   refid  st t when poll reach   delay   offset  jitter
==
 0.freebsd.pool. .POOL.  16 p-   6400.0000.000   0.004
 1.freebsd.pool. .POOL.  16 p-   6400.0000.000   0.004
 2.freebsd.pool. .POOL.  16 p-   6400.0000.000   0.004
+125.255.139.115 130.194.1.96 2 u   27  128  377   43.168   -5.505   0.924
+203.23.237.200  203.35.83.2422 u   26  128  377   29.877   -4.786   0.749
-121.0.0.42  23.31.237.1123 u  212  256  377   46.560   -2.756   5.783
*54.252.165.245  202.21.137.102 u   25  128  377   30.060   -4.859   0.783
-2001:418:3ff::1 204.123.2.72 2 u  165  256  377  173.324   -1.592   1.651
-2001:df0:fe:2:: 130.102.2.1233 u  106  256  377   44.1774.080   3.690
+130.102.2.123   216.218.254.202  2 u   20  128  377   46.288   -4.332   1.416

The same server running an un-patched ntp.conf looks like this.

rwsrv02> ntpq -np
 remote   refid  st t when poll reach   delay   offset  jitter
==
*54.252.165.245  202.21.137.102 u   32   64   17   31.100   -7.764   3.887
+202.127.210.37  130.102.2.1233 u   32   64   17   40.1812.001   2.074
+2001:df0:fe:2:: 130.102.2.1233 u   32   64   17   45.9742.414   2.502

-- 
John Marshall


pgp2bX3AHP32o.pgp
Description: PGP signature

Re: MFC r282973 (disable libgomp build) and r283060 (disable libgcov build)?

2015-07-23 Thread Matthieu Volat 
On Mon, 20 Jul 2015 14:03:01 -0700 (PDT)
Don Lewis  wrote:

> Should r282973 and r283060 be MFCed to FreeBSD 10?  On amd64 and i386,
> which use clang as their base compiler and don't have gcc in base by
> default, the math/scilab port uses clang for cc and c++ compilation, but
> finds /usr/include/omp.h (and links to libgomp from lang/gcc).  The
> build succeeds, but I suspect this may not run properly.

Does it mean the door to an openmp-enabled cc in base is closed?

I'm not fond of lang/gcc as openmp "provider": if a port use c++, it will cause 
linkage headaches with libc++ (I never was able to have graphics/darktable 
working, for example).

-- 
Matthieu Volat 


pgpS7ek1wt4jg.pgp
Description: OpenPGP digital signature