Hello Olivier,
</snip>
> > in your case we've missed the assert and are dying on uvm fault.
> >
> > you both seem to be using rdr-to. your pf seems to use also divert-to rule.
> > I suspect something is going wrong when we deal with traffic, which matches
> > rdr-to rule.
> >
> >
> > would you be so kind and try diff below on your AP box. The diff removes
> > my change to pf_state_key_link_reverse(). Which is a primary suspect
> > at the moment.
> >
> > I'm not able to trigger the panic on my notebook, nor on my
> > home router.
>
> This morning, I've rebuild a new --current kernel and got some panics after
> some minutes with PFÂ enabled.
> Then I've applied your patch and it is stable so far.
>
thank you for your help with this. I have not heard back from Sebastien yet.
one more question:
are you building your bsd kernel with DIAGNOSTIC option enabled?
I think you don't, because your crash matches uvm fault due to
use-after-free.
Sebastien hit the problem earlier by KASSERT().
just to summarize there are two boxes so far, which choked up with my commit
[1].
both boxes are quite different. yours runs bsd kernel on single core CPU:
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499
MHz, \
05-0a-02
Sebastien runs bsd.mp on two CPU cores:
cpu0: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz, 2660.30 MHz, 06-0f-0b
I'm not able to trigger crash on my HW. Which is notebbok running bsd.mp on:
cpu0: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz, 1496.74 MHz, 06-45-01
the other box, is APU router running bsd.mp on 4 cores:
cpu0: AMD GX-412TC SOC, 998.26 MHz, 16-30-01
to be honest I have no idea what could be causing problems on those two fairly
distinct machines. The strange thing is that pf_test() currently does not run in
parallel. I don't quite understand why reverting my earlier change helps here.
sorry for inconveniences
regards
sashan
[1] https://marc.info/?l=openbsd-cvs&m=161951631726837&w=2
