On 28.2.2022. 10:49, Alexandr Nedvedicky wrote:
> 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
>
do you need ddb console ? if you want i can try to reproduce this panic
without isakmpd, just hitting pfsync setup?
