On 28.11.2022. 17:07, Alexandr Nedvedicky wrote:
> diff below should avoid panic above (and similar panics in pfsync_q_del().
> It also prints some 'error' system message buffer (a.k.a. dmesg)
>
> We panic because we attempt to remove state from psync queue which is
> already empty
Hello,
>
>
> Hi,
>
> here's panic with WITNESS and this diff on tech@
> https://www.mail-archive.com/tech@openbsd.org/msg72582.html
>
> I will stop now because I'm not sure what I'm doing and which diffs I'm
> testing...
>
>
> r620-1# uvm_fault(0x8248ea28, 0x17, 0, 2) -> e
> kernel:
On 27.11.2022. 9:28, Hrvoje Popovski wrote:
> On 27.11.2022. 1:51, Alexandr Nedvedicky wrote:
>> Hello,
>>
>> On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
>>
>>> I just need to say that with all pf, pfsync and with pf_purge diffs
>>> after hackaton + this diff on tech@
>>> http
On 27.11.2022. 1:51, Alexandr Nedvedicky wrote:
> Hello,
>
> On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
>
>> I just need to say that with all pf, pfsync and with pf_purge diffs
>> after hackaton + this diff on tech@
>> https://www.mail-archive.com/tech@openbsd.org/msg72582.h
Hello,
On Sat, Nov 26, 2022 at 08:33:28PM +0100, Hrvoje Popovski wrote:
> I just need to say that with all pf, pfsync and with pf_purge diffs
> after hackaton + this diff on tech@
> https://www.mail-archive.com/tech@openbsd.org/msg72582.html
> my production firewall seems stable and it wasn't wit
Hi all,
sashan@ and dlg@ I'm sorry if your eyes bleeds from pfsync panics. I
just wanted to send panic log here after pf_purge backout.
I'm testing pfsync with NET_TASKQ=6 because I have 6 core boxes and that
way panics are faster to trigger.
In this test I sure that pf is hitting state limit quit
