Re: sysctl -a hangs ?

Hi! > >> I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro > >> X11SSZ-TLN4F board, and > >> > >> pkg install intel-ixl-kmod > >> > >> and now: > >> > >> sysctl -a > >> > >> hangs. Any quick ideas how to debug this ? > > > > If it's just not responding to anything, you can try to p

Re: sysctl -a hangs ?

On 03/21/17 17:14, hiren panchasara wrote: On 03/21/17 at 05:04P, Kurt Jaeger wrote: Hello, I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro X11SSZ-TLN4F board, and pkg install intel-ixl-kmod and now: sysctl -a hangs. Any quick ideas how to debug this ? If it's just not r

Re: sysctl -a hangs ?

On 03/21/17 at 05:04P, Kurt Jaeger wrote: > Hello, > > I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro > X11SSZ-TLN4F board, and > > pkg install intel-ixl-kmod > > and now: > > sysctl -a > > hangs. Any quick ideas how to debug this ? If it's just not responding to anything,

Re: sysctl: OID number(131) is already in use for 'me'

On 03/23/16 11:55, Eir Nym wrote: Hi, Is there method to check this with compiled binaries? Hi, You might try: strings /boot/modules/*.ko | grep me But you need to analyze the output. Possibly you could add a kdb_backtrace() call around the printf in question in the kernel. That would gi

Re: sysctl: OID number(131) is already in use for 'me'

Hi, Is there method to check this with compiled binaries? I never update world on live system since it is -CURRENT branch and I keep possible incompatibility in mind. You can also look into my build script I’ve published in same repository. — Arseny Nasokin ✪ > On 22 Mar 2016, at 19:29, Hans

Re: sysctl: OID number(131) is already in use for 'me'

Hi, Were all kernel modules in /boot/modules rebuilt? --HPS On 03/21/16 23:32, Arseny Nasokin wrote: I've recently upgrade my machine to FreeBSD-Current revision 297059 and got strange result on first boot lines: sysctl: OID number(131) is already in use for 'me' I build system in two stages

Re: sysctl -a panic on VIMAGE kernels

On Sun, Aug 9, 2015 at 6:36 AM, Gleb Smirnoff wrote: > On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: > K> Hi, > K> > K> I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’. > K> > K> Relevant backtrace bits: > K> #8 0x80e7dd28 in trap (frame=0xfe

Re: sysctl -a panic on VIMAGE kernels

On Sun, Aug 09, 2015 at 08:25:56PM +0200, Kristof Provost wrote: K> On 2015-08-09 13:36:35 (+0300), Gleb Smirnoff wrote: K> > On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: K> > K> The following fixes it for me: K> > K> K> > K> diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/

Re: sysctl -a panic on VIMAGE kernels

On 2015-08-09 13:36:35 (+0300), Gleb Smirnoff wrote: > On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: > K> The following fixes it for me: > K> > K> diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c > K> index 77d8940..3913ef3 100644 > K> --- a/sys/netinet/tcp_reass.

Re: sysctl -a panic on VIMAGE kernels

On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote: K> Hi, K> K> I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’. K> K> Relevant backtrace bits: K> #8 0x80e7dd28 in trap (frame=0xfe01f16b26a0) K> at /usr/src/sys/amd64/amd64/trap.c:426 K> #9 0x

Re: sysctl -zarc for ZFS users

2014-12-08 5:34 GMT+01:00 Yoshihiro Ota : > > Thank you for your report, Maurizio. > > I missed 'svn add zarc.c' and resuled an incompelte patch. > I uploaded a new one with a complete set to the bugzilla. > > Please try against clean directory, i.e. svn revert -R usr.bin/systat. > > Thanks, > Hiro

Re: sysctl -zarc for ZFS users

Thank you for your report, Maurizio. I missed 'svn add zarc.c' and resuled an incompelte patch. I uploaded a new one with a complete set to the bugzilla. Please try against clean directory, i.e. svn revert -R usr.bin/systat. Thanks, Hiro On Sat, 6 Dec 2014 15:28:05 +0100 "Ranjan1018 ." <21474.

Re: sysctl -zarc for ZFS users

2014-12-06 11:35 GMT+01:00 Yoshihiro Ota : > Hi all. > > I've been watching ZFS activites on my machine and > improved systat to monitor such. > > One of my first goals is to watch ZFS cache statistics. > > I posted my patch to the bugzilla @ > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195

Re: sysctl: Cannot allocate memory after r267961

On 06/28/14 01:03, Hans Petter Selasky wrote: > On 06/28/14 05:42, Hans Petter Selasky wrote: >> On 06/27/14 20:51, Danilo Egea wrote: >>> Hello folks, >>> >>> I've just updated my system (current) and now I'm getting this message: >>> [danilo src$] uname -a >>> uname: sysctl: Cannot allocate memor

Re: sysctl: Cannot allocate memory after r267961

On 06/28/14 05:42, Hans Petter Selasky wrote: On 06/27/14 20:51, Danilo Egea wrote: Hello folks, I've just updated my system (current) and now I'm getting this message: [danilo src$] uname -a uname: sysctl: Cannot allocate memory Some programs are failing due this, like portmaster and chromiu

Re: sysctl: Cannot allocate memory after r267961

On 06/27/14 20:51, Danilo Egea wrote: Hello folks, I've just updated my system (current) and now I'm getting this message: [danilo src$] uname -a uname: sysctl: Cannot allocate memory Some programs are failing due this, like portmaster and chromium. This commit (r267961) has a lot of changes

Re: sysctl: Cannot allocate memory after r267961

On 06/27/14 20:51, Danilo Egea wrote: Hello folks, I've just updated my system (current) and now I'm getting this message: [danilo src$] uname -a uname: sysctl: Cannot allocate memory Some programs are failing due this, like portmaster and chromium. This commit (r267961) has a lot of changes

Re: sysctl add macros

PROC routine that will copy them all out in a single sysctl call.. > -Original Message- > From: John-Mark Gurney [mailto:j...@funkthat.com] > Sent: Sunday, December 01, 2013 3:00 AM > To: Venkata Duvvuru > Cc: Matthew Fleming; freebsd-current@freebsd.org > Subject: Re: sysc

RE: sysctl add macros

Message- From: John-Mark Gurney [mailto:j...@funkthat.com] Sent: Sunday, December 01, 2013 3:00 AM To: Venkata Duvvuru Cc: Matthew Fleming; freebsd-current@freebsd.org Subject: Re: sysctl add macros Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +: > The problem w

Re: sysctl add macros

ay, November 25, 2013 8:18 PM > To: Venkata Duvvuru > Cc: freebsd-current@freebsd.org > Subject: Re: sysctl add macros > > On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru > mailto:venkatkumar.duvv...@emulex.com>> wrote: > Hi, > I'm unable to figure out how t

RE: sysctl add macros

[mailto:mdf...@gmail.com] On Behalf Of Matthew Fleming Sent: Monday, November 25, 2013 8:18 PM To: Venkata Duvvuru Cc: freebsd-current@freebsd.org Subject: Re: sysctl add macros On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru mailto:venkatkumar.duvv...@emulex.com>> wrote: Hi, I'm unabl

Re: sysctl add macros

On Mon, Nov 25, 2013 at 3:35 AM, Venkata Duvvuru < venkatkumar.duvv...@emulex.com> wrote: > Hi, > I'm unable to figure out how to add an unsigned short or an unsigned char > values to a sysctl node. > SYSCTL_ADD_INT, SYSCTL_ADD_UINT, etc., are present but to add a char or a > short values I couldn

Re: sysctl: unknown oid 'kern.random.sys.harvest.interrupt

On 2013-09-21 Sat 12:46:56 +0100, RW wrote: > On Sat, 21 Sep 2013 11:14:29 +0800 > Alastair Hogge wrote: > > > On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote: > > > Hi, > > > > Hi, > > > > > I noticed the following during boot on a machine running HEAD from > > > today: > > > > I have notice

Re: sysctl: unknown oid 'kern.random.sys.harvest.interrupt

On Sat, 21 Sep 2013 11:14:29 +0800 Alastair Hogge wrote: > On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote: > > Hi, > > Hi, > > > I noticed the following during boot on a machine running HEAD from > > today: > > I have noticed this since the recent work to /sys/dev/random > > > Entropy harve

Re: sysctl: unknown oid 'kern.random.sys.harvest.interrupt

On 2013-09-16 Mon 19:21:39 +0200, Joel Dahl wrote: > Hi, Hi, > I noticed the following during boot on a machine running HEAD from today: I have noticed this since the recent work to /sys/dev/random > Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': > No such file or

Re: sysctl -a: Crashes CURRENT

On Fri, Apr 19, 2013 at 02:01:29PM +0200, O. Hartmann wrote: > trying to read the temperature on an Intel Core-i7 3930K box > (10.0-CURRENT #2 r249647: Fri Apr 19 13:22:41 CEST 2013 amd64) via > > sysctl -a|grep tempe > > crashes sporadically the system due to panic/page fault and dumps core. >

Re: sysctl panic on cold boot

I'd like to report that my notebook is now booting fine again with r248646. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebs

Re: sysctl panic on cold boot

On Thu, Mar 21, 2013 at 06:00:01AM -0700, Steve Kargl wrote: > On Thu, Mar 21, 2013 at 09:28:38AM +0100, Stefan Farfeleder wrote: > > > > since r247617 my notebook consistently crashes with a page fault when I > > turn it on. If I then reboot from the debugger, the system will boot > > just fine.

Re: sysctl panic on cold boot

On Thu, Mar 21, 2013 at 09:28:38AM +0100, Stefan Farfeleder wrote: > > since r247617 my notebook consistently crashes with a page fault when I > turn it on. If I then reboot from the debugger, the system will boot > just fine. The last known working revision is r247186. I tried backing > out r2475

Re: sysctl -a causes kernel trap 12

On 02/12/2013 12:22, Henri Hennebert wrote: > On 01/19/2013 06:58, Brandon Gooch wrote: >> On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> On 01/18/13 12:50, Brandon Gooch wrote: On Thu, Jan 10, 2013 at 4:25 PM, Xin Li >>>

Re: sysctl -a causes kernel trap 12

or rather hw.dri.0.info.i915_ringbuffer_data -- View this message in context: http://freebsd.1045724.n5.nabble.com/sysctl-a-causes-kernel-trap-12-tp5775646p5786337.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-curr

Re: sysctl -a causes kernel trap 12

If you were thinking about the same as me, is there some switch to curb hw.dri.0.info.i915_gem_hws output? -- View this message in context: http://freebsd.1045724.n5.nabble.com/sysctl-a-causes-kernel-trap-12-tp5775646p5786336.html Sent from the freebsd-current mailing list archive at Nabble.co

Re: sysctl -a causes kernel trap 12

On 01/19/2013 06:58, Brandon Gooch wrote: > On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 01/18/13 12:50, Brandon Gooch wrote: >>> On Thu, Jan 10, 2013 at 4:25 PM, Xin Li >> > wrote: >>> >>> -BEGIN P

Re: sysctl -a causes kernel trap 12

On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 01/18/13 12:50, Brandon Gooch wrote: > > On Thu, Jan 10, 2013 at 4:25 PM, Xin Li > > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > > > > To all

Re: sysctl -a causes kernel trap 12

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/18/13 12:50, Brandon Gooch wrote: > On Thu, Jan 10, 2013 at 4:25 PM, Xin Li > wrote: > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > > To all: this became more and more hard to replicate lately. I've > tri

Re: sysctl -a causes kernel trap 12

On Thu, Jan 10, 2013 at 4:25 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > To all: this became more and more hard to replicate lately. I've > tried these options and the most important progress is that it's > possible to get a crashdump when debug.debugger_on_panic=0

Re: sysctl -a causes kernel trap 12

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To all: this became more and more hard to replicate lately. I've tried these options and the most important progress is that it's possible to get a crashdump when debug.debugger_on_panic=0 and I managed to get a backtrace which indicates the panic o

Re: sysctl -a causes kernel trap 12

d wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 1/7/13 5:33 PM, Brandon Gooch wrote: > > On Mon, Jan 7, 2013 at 6:09 PM, Xin Li > > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > > > > On 01/07/13 16:02, Konstantin Belousov wrote:

Re: sysctl -a causes kernel trap 12

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/7/13 5:33 PM, Brandon Gooch wrote: > On Mon, Jan 7, 2013 at 6:09 PM, Xin Li > wrote: > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > > On 01/07/13 16:02, Konstantin Belousov wrote: >> On Mon, Jan 07, 2013 at

Re: sysctl -a causes kernel trap 12

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/7/13 4:21 PM, Ryan Stone wrote: > Have you tried dropping into the debugger by setting > debug.debugger_on_panic=1 instead of trying to generate a core? > You might have some success generating at least a backtrace. My setting was debugger on

Re: sysctl -a causes kernel trap 12

On Mon, Jan 7, 2013 at 6:09 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 01/07/13 16:02, Konstantin Belousov wrote: > > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >> > >> Hi, > >> > >> I've recentl

Re: sysctl -a causes kernel trap 12

On Mon, Jan 7, 2013 at 7:21 PM, Ryan Stone wrote: > Have you tried dropping into the debugger by setting > debug.debugger_on_panic=1 instead of trying to generate a core? You might > have some success generating at least a backtrace. > Sigh, reading comprehension fail on my part. Try generatin

Re: sysctl -a causes kernel trap 12

Have you tried dropping into the debugger by setting debug.debugger_on_panic=1 instead of trying to generate a core? You might have some success generating at least a backtrace. Also it would be worth setting kern.stop_scheduler_on_panic=0 to see if that lets you generate a core.

Re: sysctl -a causes kernel trap 12

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/07/13 16:02, Konstantin Belousov wrote: > On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Hi, >> >> I've recently (by mid-December I think) noticed that sysctl -a >> can sometim

Re: sysctl -a causes kernel trap 12

On Mon, Jan 07, 2013 at 03:54:23PM -0800, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > I've recently (by mid-December I think) noticed that sysctl -a can > sometimes cause kernel trap 12. Tried enabling INVARIANTS and the > problem mysteriously disappeared. Afte

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, On Wed, Oct 03, 2012 at 10:15:32PM +0200, Andre Oppermann wrote: > On 03.10.2012 22:03, Adrian Chadd wrote: > > > > somaxconn is the connection queue depth. If it's sitting at a couple > > hundred thousand then something else is going crazily wrong. > > > > I understand your frustration, but t

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On 10/7/12 8:02 AM, Luigi Rizzo wrote: Coming to 802.11 (and I am using it just as an example): configuration of the various parameters is not too different from, say, manipulating the various features that are available in modern NICs: interrupt mitigation, queue parameters, multiqueue support,

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On Sun, Oct 07, 2012 at 01:05:21PM -0400, Justin Hibbits wrote: > On Sun, 07 Oct 2012 10:16:40 -0600 > Ian Lepore wrote: > > > On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > > > Access through sysctl is incredibly easy from both userspace and > > > from a C application, because all the w

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On Sun, 07 Oct 2012 10:16:40 -0600 Ian Lepore wrote: > On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > > Access through sysctl is incredibly easy from both userspace and > > from a C application, because all the work is done in the kernel > > side, whereas other mechanisms (ioctl, i'd rat

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On Sun, 2012-10-07 at 17:53 +0200, Luigi Rizzo wrote: > Access through sysctl is incredibly easy from both userspace and > from a C application, because all the work is done in the kernel > side, whereas other mechanisms (ioctl, i'd rather leave kvm apart > as we really don't want that!) require th

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On Sun, Oct 07, 2012 at 08:23:23AM -0700, Garrett Cooper wrote: > On Sun, Oct 7, 2012 at 8:02 AM, Luigi Rizzo wrote: ... > FWIW, I don't think that the problem is necessarily the fact that one > should do it either via ioctl, kvm, sysctl, etc: having a library/set > of interfaces as Adrian suggest

Re: sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

On Sun, Oct 7, 2012 at 8:02 AM, Luigi Rizzo wrote: > [subject changed due to the shift of topic] > > On Sun, Oct 07, 2012 at 07:08:54AM -0700, Adrian Chadd wrote: >> On 7 October 2012 03:43, Luigi Rizzo wrote: >> > >> > Good point, thanks for mentioning this: >> >> ew. ifconfig :-) >> >> > >> >

Re: sysctl vs ifconfig vs other

> > Seconded; but compare to Linux which has mutiple different commands to > > do networking, as well as 'net'. :-) > > we do too -- we have arp, route, ifconfig, sysctl and possibly > more that i am not aware of. Note that at least arp, route and ifconfig have been there since very early BSD rel

sysctl vs ifconfig vs other (was Re: sysctl-controlled key-value store ?)

[subject changed due to the shift of topic] On Sun, Oct 07, 2012 at 07:08:54AM -0700, Adrian Chadd wrote: > On 7 October 2012 03:43, Luigi Rizzo wrote: > > > > Good point, thanks for mentioning this: > > ew. ifconfig :-) > > > > > Could be done, but I consider the ifconfig one of the ugliest >

Re: sysctl-controlled key-value store ?

On 7 October 2012 03:43, Luigi Rizzo wrote: > > Good point, thanks for mentioning this: ew. ifconfig :-) > > Could be done, but I consider the ifconfig one of the ugliest > configuration mechanisms we have in FreeBSD so I'd rather not > contribute to that. Seconded; but compare to Linux which

Re: sysctl-controlled key-value store ?

On Sun, Oct 07, 2012 at 12:57:42PM +1300, Andrew Thompson wrote: > On 7 October 2012 06:28, Luigi Rizzo wrote: > > Hi, > > in order to control some netmap feature (namely, which interfaces > > are attached to VALE switches), i would considering the use of > > a sysctl interface triggering a sysctl

Re: sysctl-controlled key-value store ?

On 7 October 2012 06:28, Luigi Rizzo wrote: > Hi, > in order to control some netmap feature (namely, which interfaces > are attached to VALE switches), i would considering the use of > a sysctl interface triggering a sysctl-proc, something of the form > > dev.netmap.switch.xyz=em0 ix1 >

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote: > On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: > >In addition we had to migrate all our mysql servers from freebsd to debian > >because they were hitting some arbitary OS limit but I could never figure > >out what, sys%

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 5 October 2012 05:26, Ivan Voras wrote: > On 03/10/2012 22:15, Andre Oppermann wrote: > >> I guess the problem is rather kern.ipc.maxsockets which is only 25600. > >> maxsockets should be bumped up quite a bit by default IMO. How far needs >> some analysis because there are some dependencies an

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 03/10/2012 22:15, Andre Oppermann wrote: > I guess the problem is rather kern.ipc.maxsockets which is only 25600. > maxsockets should be bumped up quite a bit by default IMO. How far needs > some analysis because there are some dependencies and memory > requirements. So, how about a heuristic

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 4 October 2012 15:21, Peter Jeremy wrote: > On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: >>In addition we had to migrate all our mysql servers from freebsd to debian >>because they were hitting some arbitary OS limit but I could never figure >>out what, sys% usage went through

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: >In addition we had to migrate all our mysql servers from freebsd to debian >because they were hitting some arbitary OS limit but I could never figure >out what, sys% usage went through the roof when this limit was hit, issue >didnt occ

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, Oct 3, 2012 at 3:03 PM, Ryan Stone wrote: >>> Or the TTL of TCP connections might be too high for the volume of >>> connections received. Someone else on net@ reported that changing >>> this value to more aggressively reap sockets improved performance >>> greatly (at the cost that more con

Re: sysctl kern.ipc.somaxconn limit 65535 why?

>> Or the TTL of TCP connections might be too high for the volume of >> connections received. Someone else on net@ reported that changing >> this value to more aggressively reap sockets improved performance >> greatly (at the cost that more connections potentially needing to >> be reestablished and

Re: sysctl kern.ipc.somaxconn limit 65535 why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/12 13:47, Garrett Cooper wrote: > On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd > wrote: >> Hi, >> >> somaxconn is the connection queue depth. If it's sitting at a >> couple hundred thousand then something else is going crazily >> wrong. >>

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd wrote: > Hi, > > somaxconn is the connection queue depth. If it's sitting at a couple > hundred thousand then something else is going crazily wrong. > > I understand your frustration, but there's a lot of instances where > the application just isn't doi

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 03.10.2012 22:03, Adrian Chadd wrote: Hi, somaxconn is the connection queue depth. If it's sitting at a couple hundred thousand then something else is going crazily wrong. I understand your frustration, but there's a lot of instances where the application just isn't doing things "right" and

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On 3 October 2012 13:01, Garrett Cooper wrote: > > Here's where it's being held at 65535 (sys/kern/kern_uipc.c): > > 3276 static int > 3277 sysctl_somaxconn(SYSCTL_HANDLER_ARGS) > 3278 { > 3279 int error; > 3280 int val; > 3281 > 3282 val = somaxconn; > 3283 error =

Re: sysctl kern.ipc.somaxconn limit 65535 why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 10/03/12 11:45, free...@chrysalisnet.org wrote: > Hi everyone. > > Actually 65k sockets is incredibly easy to reach. No, this is not kern.ipc.maxsockets. kern.ipc.somaxconn is for "baclkog" and not the maximum connections. Accumulating 64K

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, somaxconn is the connection queue depth. If it's sitting at a couple hundred thousand then something else is going crazily wrong. I understand your frustration, but there's a lot of instances where the application just isn't doing things "right" and the OS tries to hide it as much as psosible

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, Oct 3, 2012 at 11:45 AM, wrote: > Hi everyone. > > Actually 65k sockets is incredibly easy to reach. > > I manage some servers for a very large website, it currently has several > http servers clustered to handle daily traffic and this is only dynamic > content, static has its own servers

Re: sysctl filesystem ?

On 26 Jun 2012, at 15:42, m...@freebsd.org wrote: > While I understand the problems you allude to, the sysctl(8) binary > can protect itself from them. IMO the biggest problem with sysctls > not being files is that it makes no sense from the core UNIX > philosophy that everything is a file. Soc

Re: sysctl filesystem ?

On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote: > On Tue, 26 Jun 2012, Chris Rees wrote: > >>> as well as we don't depend of /proc for normal operation we shouldn't for >> >> say /proc/sysctl >>> >>> >>> improvements are welcome, better documentation is welcome, changes to >> >> what is OK -

Re: sysctl filesystem ?

and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a bette

Re: sysctl filesystem ?

as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.o

Re: sysctl filesystem ?

> > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful.  Just because Linux uses it doesn't make it a bad idea. actually - i don'

Re: sysctl filesystem ?

On Tue, 26 Jun 2012, Chris Rees wrote: as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make

Re: sysctl filesystem ?

On Jun 26, 2012 7:07 AM, "Wojciech Puchar" wrote: > > as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl > > improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it

Re: sysctl filesystem ?

Hi, On Mon, Jun 25, 2012 at 10:51 PM, Boris Popov wrote: > On 26.06.2012 6:56, Arnaud Lacombe wrote: >> purpose. However, if I can avoid to re-design that wheel too, by >> getting access to scfs(4) code, I will. > >  It is interesting, that the old drive with this code are still alive. > Most lik

Re: sysctl filesystem ?

On 26.06.2012 6:56, Arnaud Lacombe wrote: > purpose. However, if I can avoid to re-design that wheel too, by > getting access to scfs(4) code, I will. It is interesting, that the old drive with this code are still alive. Most likely, FS related part will need serious attention because of numerou

Re: sysctl filesystem ?

On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper wrote: > On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote: >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: >> >> from `src/sbin/sysctl.c': >> /* >>

Re: sysctl filesystem ?

Hi, On Mon, Jun 25, 2012 at 8:30 PM, Adam Vande More wrote: > On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: >> >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: > > There is this: > > http://s

Re: sysctl filesystem ?

On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > There is this: http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ -- Adam Vande More

Re: sysctl filesystem ?

On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > > from `src/sbin/sysctl.c': > /* >  * These functions uses a presently undocumented interface to the

Re: sysctl kern.ipc.somaxconn limit 65535 why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/04/12 17:49, Chuck Swiger wrote: > Hi, Xin-- > > On Jan 4, 2012, at 5:32 PM, Xin Li wrote: >> I am personally quite convinced that FreeBSD should make such >> change though -- having more than 64K of outstanding and >> unhandled connections does

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, Xin-- On Jan 4, 2012, at 5:32 PM, Xin Li wrote: > I am personally quite convinced that FreeBSD should make such change > though -- having more than 64K of outstanding and unhandled > connections does not sound a great idea (i.e. it's not a connection > limit after all, but the pending handle c

Re: sysctl kern.ipc.somaxconn limit 65535 why?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/04/12 16:09, Dan The Man wrote: > > On Wed, 4 Jan 2012, Chuck Swiger wrote: > >> Hi-- >> >> On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if neede

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Jan 4, 2012, at 4:09 PM, Dan The Man wrote: >>> With the new IBM developments underway of 16 core atom processors and >>> hundreds of gigabytes of memory, surely a backlog of 100k is manageable. Or >>> what about the future of 500 core systems with a terrabyte of memory, 100k >>> listen queue

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, 4 Jan 2012, Chuck Swiger wrote: Hi-- On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: It is not arbitrary. Systems ought to provide sensible limits, which can be adjusted if needed and appropriate. The fact that a system might have 50,000 file descriptors globally available does not

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi-- On Jan 4, 2012, at 2:23 PM, Dan The Man wrote: >> It is not arbitrary. Systems ought to provide sensible limits, which can be >> adjusted if needed and appropriate. The fact that a system might have >> 50,000 file descriptors globally available does not mean that it would be OK >> for an

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, On Wed, Jan 4, 2012 at 2:50 PM, Dan The Man wrote: [...] > How about a sensible solution? I think everyone has been making valid points > here, about sensible limits for all programs on system and per application > limit changes. > > How about changing the hard limit high, and an application

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, 4 Jan 2012, Dan The Man wrote: On Wed, 4 Jan 2012, Chuck Swiger wrote: On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: Hi, On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: However, I'm not convinced that it is useful to do this

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, On Wed, Jan 4, 2012 at 3:22 PM, Dan The Man wrote: > > > sunsaturn:~# sysctl -w kern.ipc.somaxconn=20 > kern.ipc.somaxconn: 4096 > sysctl: kern.ipc.somaxconn: Invalid argument > sunsaturn:~# sysctl -w kern.ipc.somaxconn=65536 > kern.ipc.somaxconn: 4096 > sysctl: kern.ipc.somaxconn: Invali

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, 4 Jan 2012, Chuck Swiger wrote: On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: Hi, On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: However, I'm not convinced that it is useful to do this. At some point, you are better off timi

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: >> On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: However, I'm not convinced that it is useful to do this. At some point, you are better off timing out and retrying via expo

Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi, On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger wrote: > On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >>> However, I'm not convinced that it is useful to do this.  At some point, >>> you are better off timing out and retrying via exponential backoff than you >>> are queuing hundreds of thous

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >> However, I'm not convinced that it is useful to do this. At some point, you >> are better off timing out and retrying via exponential backoff than you are >> queuing hundreds of thousands of connections in the hopes that they will >> eventually

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Jan 4, 2012, at 12:22 PM, Dan The Man wrote: > Trying to stress test a framework here that tosses 100k of connections into a > listen queue before doing anything, I realize I'll have to use multiple local > IPs get get around port limitations, but why is this backlog using a limit? Even a bac

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, 4 Jan 2012, Dan The Man wrote: On Wed, 4 Jan 2012, Chuck Swiger wrote: On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog i

Re: sysctl kern.ipc.somaxconn limit 65535 why?

On Wed, 4 Jan 2012, Chuck Swiger wrote: On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm

  1   2   >