;> give
> > >> you something reasonable:
> > >>
> > >> pfctl -a '*' -vvsr
> > >> pfctl -a 'ext1' -vvsr
> > >> pfctl -a 'ext2' -vvsr
> > >
> > > Thanks, "panic: no appropriate pool f
t; give
>>>> you something reasonable:
>>>>
>>>> pfctl -a '*' -vvsr
>>>> pfctl -a 'ext1' -vvsr
>>>> pfctl -a 'ext2' -vvsr
>>>
>>> Thanks, "panic: no appropriate pool for 23/23" is the
ff to see which rule the state belongs to. since you're using
> >> anchors, figuring
> >> out rule numbers will not be easy but you may try to see if one of those
> >> give
> >> you something reasonable:
> >>
> >> pfctl -a '*' -vvsr
uring
>> out rule numbers will not be easy but you may try to see if one of those give
>> you something reasonable:
>>
>> pfctl -a '*' -vvsr
>> pfctl -a 'ext1' -vvsr
>> pfctl -a 'ext2' -vvsr
>
> Thanks, "panic: no appropria
treat the
>> associated rules accordingly.
>>
>
> most likely it's triggered by the reply-to statement. you may try the
> attached
> diff to see which rule the state belongs to. since you're using
> anchors, figuring
> out rule numbers will not be easy but
(nr->rdr.addr.type != PF_ADDR_NONE)
rpool = nr->rdr;
else if (nr->nat.addr.type != PF_ADDR_NONE)
@@ -873,7 +874,8 @@ pf_postprocess_addr(struct pf_state *cur)
else if (nr->route.addr.type != PF_ADDR_NONE)
rpool = nr->route;
else
On 08/01/15 19:31, Jonathan Gray wrote:
> On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote:
>> [... snip ...]
>> You're slightly overanalyzing here: panic has caught the unhandled
>> case, but it's not needed per se.
>>
>
> The code directly after the panic assumes rpool is set.
>
On Sat, Aug 01, 2015 at 08:46:00PM +0200, Mike Belopuhov wrote:
> On 1 August 2015 at 19:20, RD Thrush wrote:
> >
> > The patch ran without panic for 20+ hours.
> >
>
> Thanks for testing!
>
> > I wondered about the removal of the panic() statement so I tried
> > another kernel that added the me
On 08/01/15 14:46, Mike Belopuhov wrote:
> On 1 August 2015 at 19:20, RD Thrush wrote:
>>
>> The patch ran without panic for 20+ hours.
>>
>
> Thanks for testing!
>
>> I wondered about the removal of the panic() statement so I tried
>> another kernel that added the memset() but kept the panic()
On 1 August 2015 at 19:20, RD Thrush wrote:
>
> The patch ran without panic for 20+ hours.
>
Thanks for testing!
> I wondered about the removal of the panic() statement so I tried
> another kernel that added the memset() but kept the panic() statement, as
> follows:
>
[snip]
>
> That kernel pan
0644
> --- sys/net/pf_lb.c
> +++ sys/net/pf_lb.c
> @@ -866,14 +866,13 @@ pf_postprocess_addr(struct pf_state *cur)
> }
>
> /* check for appropriate pool */
> + memset(&rpool, 0, sizeof(rpool));
> if (nr->rdr.addr.type != PF_ADDR_NONE)
>
&rpool, 0, sizeof(rpool));
> if (nr->rdr.addr.type != PF_ADDR_NONE)
> rpool = nr->rdr;
> else if (nr->nat.addr.type != PF_ADDR_NONE)
> rpool = nr->nat;
> else if (nr->route.addr.type != PF_ADDR_NONE)
> rpool = nr->route;
> - else
> - panic("no appropriate pool");
>
> if (((rpool.opts & PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES))
> return (0);
>
mset(&rpool, 0, sizeof(rpool));
if (nr->rdr.addr.type != PF_ADDR_NONE)
rpool = nr->rdr;
else if (nr->nat.addr.type != PF_ADDR_NONE)
rpool = nr->nat;
else if (nr->route.addr.type != PF_ADDR_NONE)
rpool = nr->route;
- else
- panic("no appropriate pool");
if (((rpool.opts & PF_POOL_TYPEMASK) != PF_POOL_LEASTSTATES))
return (0);
On Fri, Jul 31, 2015 at 10:57 -0400, RD Thrush wrote:
> >Synopsis:panic in sys/net/pf_lb.c
> >Category:kernel
> >Environment:
> System : OpenBSD 5.8
> Details : OpenBSD 5.8 (GENERIC) #1047: Thu Jul 30 23:24:48 MDT 2015
>
> dera...@i386.openbsd.or
00
0x00d0:
0x00e0: 00000000
0x00f0:
acpidump:
ddb session #
login: panic: no appropriate pool
Stopped at D
15 matches
Mail list logo
