Hello,

</snip>
> > i will still play with sasyncd setup, maybe something comes up
> > 
> 
> And when I thought everything is fine.. after 2 days of hitting sasyncd
> setup I've got this panic .. will stay in ddb if some other information
> is needed
> 

    I think you are hitting a different issue, which could be hiding there
    for a while.

</snip>
> 
> 
> ddb{1}> trace
> pfsync_sendout() at pfsync_sendout+0x5a5
> pfsync_update_state(fffffd8425b77030) at pfsync_update_state+0x15b
> pf_test(2,3,ffff8000000c2048,ffff800022c71dd8) at pf_test+0xd61
> ip_output(fffffd8007117b00,0,ffff800022c71f68,1,0,0,e436e0ec669ea3ac) at
> ip_out
> put+0x6b7
> ip_forward(fffffd8007117b00,ffff800000099048,fffffd842d596cb8,0) at
> ip_forward+
> 0x2da
> ip_input_if(ffff800022c720a8,ffff800022c720b4,4,0,ffff800000099048) at
> ip_input
> _if+0x353
> ipv4_input(ffff800000099048,fffffd8007117b00) at ipv4_input+0x39
> ether_input(ffff800000099048,fffffd8007117b00) at ether_input+0x3ad
> if_input_process(ffff800000099048,ffff800022c72198) at if_input_process+0x92
> ifiq_process(ffff800000098800) at ifiq_process+0x69
> taskq_thread(ffff80000002f200) at taskq_thread+0x100
> end trace frame: 0x0, count: -11

    we die here in pfsync_sendout() at linet 1871 (given I can trust gdb):

1861         /* walk the queues */
1862         for (q = 0; q < PFSYNC_S_COUNT; q++) {
1863                 if (TAILQ_EMPTY(&sn.sn_qs[q]))
1864                         continue;
1865 
1866                 subh = (struct pfsync_subheader *)(m->m_data + offset);
1867                 offset += sizeof(*subh);
1868 
1869                 count = 0;
1870                 while ((st = TAILQ_FIRST(&sn.sn_qs[q])) != NULL) {
1871                         TAILQ_REMOVE(&sn.sn_qs[q], st, sync_list);
1872 #ifdef PFSYNC_DEBUG
1873                         KASSERT(st->sync_state == q);
1874 #endif
1875                         st->sync_state = PFSYNC_S_NONE;
1876                         pfsync_qs[q].write(st, m->m_data + offset);
1877                         offset += pfsync_qs[q].len;
1878 
1879                         pf_state_unref(st);
1880                         count++;
1881                 }
1882 

    I need to poke to disasm more closely to figure out, which queue (`q`)
    we are processing when we die, this might get us closer to culprit.
    those queues belong to pf(4), so I see tdb/ipsec to be innocent here.

    I'll try to take a look later today.

thanks and
regards
sashan

Reply via email to