On 1 August 2015 at 19:20, RD Thrush <[email protected]> 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 panic'd as before with "no appropriate pool". Well of course. Not all rules are rdr/nat/route-to. > Was the Jul 20 cvs commit (panic addition) incorrect? It has served it's purpose well: it has found this bug. But panic'ing here in general is of course incorrect. > If not, it appears the memset() addition didn't fix the panic. > It did, clearly. You can run your setup again (-: > I was able to take a crash dump with the above change and have > attached a gdb transcript. The stack is apparently damaged in the > pf_postprocess_addr() function; however, I'm over my head at this > point. How may I help further troubleshoot? You're slightly overanalyzing here: panic has caught the unhandled case, but it's not needed per se.
