Now, after several tests I can state that problem is there. I made sure that /usr/src is clean and up to date (I had Hennings diffs on test).
The stock -current kernel crashes with this behavior, eg. panic and loop with mtx_enter on console. This bug is triggered then I transfer /bsd over IPSec. While scp from the same machine, but on public side goes fine. client (network1)<-----> fw1 ---> [---- ospf over gre over ipsec] <----- fw2 <-------->network2 client does 'scp fw2.network2_ip:/bsd .' - results in panic. client does 'scp fw2.public_ip:/bsd .' - all fine. Of cause I have CARP both on external and internal sides of fw2. CARP for internal network on fw1. Side note is that I noticed drastic speed drop just before system goes in panic. Normally I have decent speed between two networks, e.g. transfers from clients on network2 to client on network1. Any ideas? //mxb On 3 jan 2013, at 13:39, Stuart Henderson <[email protected]> wrote: > On 2013-01-03, mxb <[email protected]> wrote: >> Sorry for the noise. I think I'v found the problem. > > Any more information on what it was?? > Even if it was something you've done, that should't happen.. > > > >>> On 1 jan 2013, at 19:11, mxb <[email protected]> wrote: >>>> >>>> I'v got yet another panic. >>>> This time, after applying Martin Pelikans' diff, catched a pointer. >>>> However, machine never drops to ddb, even sysctl.conf says it should. >>>> >>>> panic: mxt_enter: locking against myself, 0xffffffff80a2d540 >>>> kernel: privileged instruction fault trap, code=0 >>>> kernel: double fault trap, code=0 >>>> >>>> I was able to reproduce this several times and whenever I wanted it. >>>> >>>> Here is scenario(or setup) then I was able to trigger: >>>> Two networks with OSPF-routing on top of GRE on top of IPSec. >>>> Client on network1 starts scp-download from a firewall(fw1) on network2. >>>> fw1 acts as a VPN/OSPF/GRE end-point for network2. >>>> After some time(1min or so) fw1 goes down with panic above. >>>> Basically I tried to scp down kernel from this machine. >>>> >>>> However, fw1 never goes down then I "scp up" from an Internal network >>>> behind fw1. >>>> I my case this was a patched kernel with Martins' diff from a VM-machine >>>> sitting behind fw1.
