https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
Kristof Provost changed:
What|Removed |Added
Assignee|p...@freebsd.org |freebsd-...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|p...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
Kristof Provost changed:
What|Removed |Added
Assignee|freebsd-pf@FreeBSD.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #49 from noah.bergba...@tum.de ---
At least in my particular case, I eventually tracked this down to a tunable
from loader.conf: kern.timecounter.smp_tsc_adjust=1
Since I removed that, this issue hasn't happened once so I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #48 from h...@restart.be ---
(In reply to Kristof Provost from comment #47)
No. I am running on a Pine64+ 2GB
See http://docs.freebsd.org/cgi/mid.cgi?fdf7ea24-6ada-dbb1-146a-0bf6fde11d29
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #47 from Kristof Provost ---
(In reply to hlh from comment #46)
Are you also using VMWare esxi?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
freebsd.po...@webstyle.ch changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #44 from Kristof Provost ---
(In reply to hlh from comment #43)
No, that shouldn't matter, unless the clock is completely wrong (i.e. not
running, or running orders of magnitude slower than expected, or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #43 from h...@restart.be ---
(In reply to Kristof Provost from comment #42)
I upgrade the PINE64 to CURRENT 324563 and now ntpd can't keep the clock for a
long time - after one hour or 2, the clock run too fast. I think that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #42 from Kristof Provost ---
(In reply to hlh from comment #40)
> dtrace: processing aborted: Abort due to systemic unresponsiveness
You'd have to talk to a dtrace specialist about that. I'm not sure what
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #41 from Kristof Provost ---
(In reply to hlh from comment #38)
> Why ARC at 233% and 1727Mb wired?
The ARC now keeps compressed data, so you can fit more in memory. I suspect
that's a result of that.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #40 from h...@restart.be ---
(In reply to hlh from comment #33)
When I run the dtrace in batch, it end freqently with:
dtrace: script './pf.dtrace2' matched 2 probes
dtrace: buffer size lowered to 2m
dtrace: processing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #39 from h...@restart.be ---
(In reply to Kristof Provost from comment #37)
I'm really sorry because in my previous post I display the tail of
dtrace2.log-after instead of dtrace2.log-before. I have deleted those files;
Shame on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #38 from h...@restart.be ---
(In reply to Kristof Provost from comment #37)
The only thing that seems strange to me is the memory used on this system:
top show:
last pid: 37231; load averages: 0.19, 0.20, 0.16
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #37 from Kristof Provost ---
I do not understand this at all. There is no reason for the purge thread to get
stuck. There's also no reason for it apparently having run 7 times between
freezing and when you
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #36 from h...@restart.be ---
I notice that when I do:
echo "set timeout interval 10" | pfctl -mf -
while pf is running without problem, then no more state are created.
I must run `nohup service pf restart`to restore a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #35 from h...@restart.be ---
(In reply to hlh from comment #33)
The problem crops up again.
Here is the end of the output of your dtrace script when the states are no more
expired:
[root@norquay log]# tail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #34 from h...@restart.be ---
(In reply to Kristof Provost from comment #32)
I check the troubling number of return:
[root@norquay log]# grep entry pf.dtrace1.log-before |wc -l
2026647
[root@norquay log]# grep return
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #33 from h...@restart.be ---
(In reply to Kristof Provost from comment #32)
Here is the dtrace script used:
#!/usr/sbin/dtrace -s
fbt:kernel:pf_purge_expired_states:entry
{
}
fbt:kernel:pf_purge_expired_states:return
{
}
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #32 from Kristof Provost ---
(In reply to hlh from comment #31)
It's a little odd that you're seeing double pf_purge_expired_states:return
entries.
Any chance you've got two such probes in your dtrace script?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #31 from h...@restart.be ---
(In reply to Kristof Provost from comment #27)
When the problem occurs, no more line in the dtrace log.
Here are the last 20 lines:
[root@norquay ~]# tail -n 20 /var/log/pf.dtrace.log-before
0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #30 from Kristof Provost ---
(In reply to noah.bergbauer from comment #29)
Having checked the code, yes, I believe you're correct about that.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #29 from noah.bergba...@tum.de ---
>>I don't understand why your 'pfctl -si' would then only show 31 states.
>I think that the `pfctl -si` shows the counters just when the problem start.
It's the same for me. As far as I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #28 from h...@restart.be ---
I think that the `pfctl -si` shows the counters just when the problem start.
I'm running dtrace from now on.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #27 from Kristof Provost ---
(In reply to hlh from comment #26)
I don't understand why your 'pfctl -si' would then only show 31 states.
Either way, it would be interesting to run the dtrace script constantly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #26 from h...@restart.be ---
The first time I detected this problem was when a computer was not allow a
connection to the internet. I check the gateway (the pine64 running CURRENT)
and find the 'PF states limit reached' in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #25 from Kristof Provost ---
(In reply to hlh from comment #24)
Wait? You don't see 'PF states limit reached'? What are you seeing, exactly,
and how do you detect it?
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #24 from h...@restart.be ---
I run the pfctl -si after I detected the problem (with pftop) and before
attempting any workaround.
Here is the typical top:
last pid: 38563; load averages: 0.15, 0.28, 0.25
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #23 from Kristof Provost ---
(In reply to hlh from comment #22)
Did you take that '# pfctl -si' before attempting any of the workarounds? It
shows you've got 31 states, I don't see how you'd hit the state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #22 from h...@restart.be ---
The problem crop up:
[root@norquay ~]# pfctl -si
Status: Enabled for 1 days 08:09:42 Debug: Urgent
Interface Stats for ng0 IPv4 IPv6
Bytes In
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #21 from h...@restart.be ---
Here is my pf.conf:
# $FreeBSD: src/etc/pf.conf,v 1.3 2006/01/27 17:16:20 mlaier Exp $
# $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $
#
# See pf.conf(5) and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #20 from h...@restart.be ---
The same workaround is working for me:
echo "set timeout interval 5" | pfctl -mf -
echo "set timeout interval 10" | pfctl -mf -
but to be sure I also do:
nohup service pf restart
For more than 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
h...@restart.be changed:
What|Removed |Added
CC||h...@restart.be
--- Comment #18
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #17 from Max ---
(In reply to Kristof Provost from comment #15)
You are right. It is not the problem. But it looks quite similar.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #16 from Max ---
(In reply to noah.bergbauer from comment #14)
I'll try to reproduce the problem. But I need some starting point. Rules, dead
connections state entries... Anything?
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #15 from Kristof Provost ---
(In reply to noah.bergbauer from comment #14)
Given the nature of your workaround and what we've seen from Dtrace I don't
think that #217997 is the problem.
I'm also pretty sure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #14 from noah.bergba...@tum.de ---
(In reply to Max from comment #13)
Maybe, maybe not. The point of my workaround is to get a mostly functioning
machine. However, the reboot right before this period was necessary because for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #13 from Max ---
(In reply to noah.bergbauer from comment #12)
> Status: Enabled for 1 days 14:44:53
Have you had any issues during this period?
And do you know which rule produces expired states?
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
--- Comment #12 from noah.bergba...@tum.de ---
set limit { states 10, src-nodes 1 }
One of my first attempts to fix this was increasing both limits 10x - didn't
help though.
# pfctl -vsi
No ALTQ support in kernel
ALTQ related
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
Max changed:
What|Removed |Added
CC||maxi...@als.nnov.ru
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org
41 matches
Mail list logo