On Sun, Feb 16, 2014 at 2:57 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
This adds support for a few more instruction patterns that are
apparentl needed by gcc 4.8. Taken from binutils 2.17. Not sure if
adding NoRex64 to the existing patterns is really necessary, but it
shouldn't hurt.
Thank you! This solved my problem.
The limit was reached several times within few seconds.
Give this man a medal.
Best regards
Alex Mathiasen
-Oprindelig meddelelse-
Fra: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] På vegne af Philipp
Sendt: 16. februar 2014 19:19
Til:
Am 17.02.2014 09:22 schrieb Alex Mathiasen:
Thank you! This solved my problem.
Cheers.. found the hard way the other day.
There should really be some dmesg when state-tables overflow.
This silent dropping is wasting time in debugging such situations.
Sorry for talk instead of diff :-}
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.37
diff -p -u -r1.37 uvm_pmemrange.c
--- uvm/uvm_pmemrange.c 6 Feb 2014 16:40:40 - 1.37
+++ uvm/uvm_pmemrange.c 13 Feb 2014
On Mon, Feb 17, 2014 at 05:02:34PM +0800, Kieran Devlin wrote:
Probably get a better response if you explained what this diff does
and/or fixes...
-ml
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
the original implementation use identical logic for both ‘high’ ‘low’,
which will cause ‘high’ ‘low’ end up at same RB-tree node, instead of an
expected interval.
and finally, break ‘for’ loop logic
luckily all these conditions never meet in practice.
On Feb 17, 2014, at 5:14 PM, Mike Larkin
On 2014/02/17 09:35, Philipp wrote:
Am 17.02.2014 09:22 schrieb Alex Mathiasen:
Thank you! This solved my problem.
Cheers.. found the hard way the other day.
There should really be some dmesg when state-tables overflow.
This silent dropping is wasting time in debugging such situations.
On 2014/02/17 08:22, Alex Mathiasen wrote:
Thank you! This solved my problem.
The limit was reached several times within few seconds.
Give this man a medal.
Best regards
Alex Mathiasen
Sounds like you are keeping state for all connections through your bgp
router then - if you just
Am 17.02.2014 12:22 schrieb Stuart Henderson:
Writing messages that show up in dmesg is not cheap, particularly
on systems with serial console.
Well, ok. How about pflog?
* Philipp e1c1bac6253dc54a1e89ddc046585...@posteo.net [2014-02-17 13:04]:
Am 17.02.2014 12:22 schrieb Stuart Henderson:
Writing messages that show up in dmesg is not cheap, particularly
on systems with serial console.
Well, ok. How about pflog?
you made my day.
forgot the pflog format?
how
Am 17.02.2014 13:11 schrieb Henning Brauer:
how do you emit such a maessage in pcap? as payload with a dummy
packet header? (N!!)
pf is taking action without telling anyone - and that's not nice.
There *are* other log() entries in pf.c already so I wonder how the
initial
Date: Mon, 17 Feb 2014 11:22:27 +
From: Stuart Henderson st...@openbsd.org
On 2014/02/17 09:35, Philipp wrote:
Am 17.02.2014 09:22 schrieb Alex Mathiasen:
Thank you! This solved my problem.
Cheers.. found the hard way the other day.
There should really be some dmesg when
On 2014/02/17 13:36, Philipp wrote:
Am 17.02.2014 13:11 schrieb Henning Brauer:
how do you emit such a maessage in pcap? as payload with a dummy
packet header? (N!!)
pf is taking action without telling anyone - and that's not nice.
There *are* other log() entries in
* Philipp e1c1bac6253dc54a1e89ddc046585...@posteo.net [2014-02-17 13:36]:
Am 17.02.2014 13:11 schrieb Henning Brauer:
how do you emit such a maessage in pcap? as payload with a dummy
packet header? (N!!)
pf is taking action without telling anyone - and that's not nice.
On Sun, Feb 16, 2014 at 10:28:48PM -0500, James Turner wrote:
Forgot to include tech@...
Hi Andre,
I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only
have partial support but figured the report will be helpful nonetheless.
I'm currently using NUT for monitoring.
On 2014/02/17 12:56, Stuart Henderson wrote:
The log entries which are at risk of being printed frequently are
hidden by default, i.e. put behind LOG_DEBUG or similar. It seems to
me that increasing the state-limit counter is just as useful as adding
a new LOG_DEBUG for this..
Hmm. Well, I
On Mon, Feb 17, 2014 at 02:19:42PM +0100, Andre de Oliveira wrote:
On Sun, Feb 16, 2014 at 10:28:48PM -0500, James Turner wrote:
Forgot to include tech@...
Hi Andre,
I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only
have partial support but figured the report
* Stuart Henderson st...@openbsd.org [2014-02-17 14:45]:
Hmm. Well, I was assuming from the name and pfctl(8) description that
it should be state-limit, but actually it seems that is just used for
max-src-states and this case just falls under memory which is not
too descriptive.
indeed.
I
On Mon, Feb 17, 2014 at 03:21:53PM +0100, Henning Brauer wrote:
* Stuart Henderson st...@openbsd.org [2014-02-17 14:45]:
Hmm. Well, I was assuming from the name and pfctl(8) description that
it should be state-limit, but actually it seems that is just used for
max-src-states and this case
* Claudio Jeker cje...@diehard.n-r-g.com [2014-02-17 16:27]:
How much memory are 10'000 states using these days?
bit over 4MB with one state key per state.
Would it be possible to auto tune these values somehow?
I keep thinking about it - maybe sth based on physmem.
One issue I have seen is
It's only been 25 years. I think we can depend on prototypes and
const now.
Index: output.c
===
RCS file: /cvs/src/usr.bin/yacc/output.c,v
retrieving revision 1.19
diff -u -p -r1.19 output.c
--- output.c8 Jan 2014 22:55:59 -
On Mon, 17 Feb 2014 15:25:12 -0500, Ted Unangst wrote:
It's only been 25 years. I think we can depend on prototypes and
const now.
Is there really a reason to break KR compatibility in the generated
code? What problem are you solving?
- todd
On Mon, 17 Feb 2014 17:30:41 -0500, Ted Unangst wrote:
I don't see how KR compat helps us. None of the headers in
/usr/include are KR anymore. How would one compile the generated output?
You're assuming that the resulting code will be built on OpenBSD.
That's a bad assumption. The code
23 matches
Mail list logo
