rodrigc added a comment.

I tested this patch.

  # kldload pf
  # kldunload pf
  kldunload: can't unload file: Device busy

The fact that the pf module cannot be unloaded was one of the
reasons that @glebius used to back out the entire changeset last time
I committed your pf changes.  Can you fix this?

I also saw this in dmesg:

  CURVNET_SET() recursion in pfi_vnet_initialize() line 130, prev in 
      0xfffff800056e4100 -> 0xfffff800056e4100
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046389a550
  pfi_vnet_initialize() at pfi_vnet_initialize+0x21b/frame 0xfffffe046389a590
  pf_vnet_init() at pf_vnet_init+0x35/frame 0xfffffe046389a5c0
  vnet_register_sysinit() at vnet_register_sysinit+0x13c/frame 
  linker_load_module() at linker_load_module+0xc87/frame 0xfffffe046389a920
  kern_kldload() at kern_kldload+0x10e/frame 0xfffffe046389a970
  sys_kldload() at sys_kldload+0x5b/frame 0xfffffe046389a9a0
  amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe046389aab0
  Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046389aab0



To:, bz, zec, trociny, glebius, rodrigc, kristof, gnn
Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net
_______________________________________________ mailing list
To unsubscribe, send any mail to 

Reply via email to