nice 👍

i found the answer here https://forum.netgate.com/topic/152883/been-away/9

A Redmine Bug Report has been created to track this issue. Thanks for reporting it.

This seems to be fixed. I no longer need "hw.pci.enable_msix=0" in my /boot/loader.conf.local
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235147 is now closed/fixed

@Impatient said in Snapshot 430.0741:

Not in any hurry it is just a test machine.

I will need to spin up my own pfSense-2.5 package builder VM and then debug the Snort inline changes that I made to the DAQ module. Hopefully it's a simple fix in the code and then recompile.

2.5.0-DEVELOPMENT (amd64)
built on Thu Apr 30 07:41:32 EDT 2020
FreeBSD 12.1-STABLE

Working now.. :)

@jimp Many thanks! Your fix is working correctly!
Thanks for your support!

Thanks for the update.

@behemyth
I am not sure, but you can ask Netgate support directly.

@kiokoman thank you for useful info!

you are too fast man 😂
it work 💪

[2.5.0-DEVELOPMENT][root@pfSense.kiokoman.home]/dev: stty -f gps0 speed 9600 baud;

yes, i've alredy updated, i'm following your great work and no more problem for the momement 👍

I just got fixed the issue. It is due to 82583V not support MSI-X but the FreeBSD 12 haven't disabled MSI-X on such NIC. Details can be found here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235147

workaround :
Disable MSI-X by adding hw.pci.enable_msix="0" to /boot/loader.conf and reboot which fixed for me

Read https://forum.netgate.com/topic/151950/malwarebytes-feed-hphosts-offline/7- and hope with me that I'm wrong .....

Well I have like 12 subnets.
What now?

It must be on WAN, because I need to limit wan not lan.

Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x360 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e785f7 stack pointer = 0x28:0xfffffe0025b9f9a0 frame pointer = 0x28:0xfffffe0025b9fa00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: netisr 0) db:0:kdb.enter.default> bt Tracing pid 12 tid 100028 td 0xfffff8000424e580 swi_net() at swi_net+0x167/frame 0xfffffe0025b9fa00 ithread_loop() at ithread_loop+0x1a7/frame 0xfffffe0025b9fa70 fork_exit() at fork_exit+0x83/frame 0xfffffe0025b9fab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0025b9fab0

The crash is in netisr so the change you made could be related. Though I don't see how it would be related to either miniupnpd or pimd specifically.

Probably nothing that can be done there except to change that dispatch method back to the default for now. Eventually when we move 2.5.0 up to 12-STABLE you might try again.

Also, you will want to delete that attachment. The message buffer in the textdump had large chunks of your config.xml and you probably don't want all that info out there.

EDIT: I removed the attachment files from the backend. I didn't edit your post to remove the links.