PIMD crash on 2.5.0-devel
-
can't start/bind to lan on my pfsense 2.5.0-devel
Crash report begins. Anonymous machine information: amd64 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 b03a341e64a(RELENG_2_5) pfSense Crash report details: No PHP errors found. Filename: /var/crash/info.0 Dump header from device: /dev/ada0p3 Architecture: amd64 Architecture Version: 4 Dump Length: 58880 Blocksize: 512 Compression: none Dumptime: Wed Jan 29 14:47:37 2020 Hostname: pfSense.localdomain Magic: FreeBSD Text Dump Version String: FreeBSD 12.0-RELEASE-p10 b03a341e64a(RELENG_2_5) pfSense Panic String: Dump Parity: 4155007280 Bounds: 0 Dump Status: good Filename: /var/crash/textdump.tar.0 ddb.txt06000014000013614306371 7076 ustarrootwheeldb:0:kdb.enter.default> run lockinfo db:1:lockinfo> show locks No such command; use "help" to list available commands db:1:lockinfo> show alllocks No such command; use "help" to list available commands db:1:lockinfo> show lockedvnods Locked vnodes db:0:kdb.enter.default> show pcpu cpuid = 1 dynamic pcpu = 0xfffffe007f572ac0 curthread = 0xfffff8000433a580: pid 12 tid 100038 "swi1: netisr 0" curpcb = 0xfffffe000046fb80 fpcurthread = none idlethread = 0xfffff800042aa580: tid 100004 "idle: cpu1" curpmap = 0xffffffff82c8bd88 tssp = 0xffffffff82db7488 commontssp = 0xffffffff82db7488 rsp0 = 0xfffffe000046fb80 gs32p = 0xffffffff82dbe0c0 ldt = 0xffffffff82dbe100 tss = 0xffffffff82dbe0f0 curvnet = 0 -
That isn't from pimd, it's something wrong in general with your host system.
db:0:kdb.enter.default> bt Tracing pid 12 tid 100038 td 0xfffff8000433a580 swi_net() at swi_net+0x167/frame 0xfffffe000046fa00 ithread_loop() at ithread_loop+0x1a7/frame 0xfffffe000046fa70 fork_exit() at fork_exit+0x83/frame 0xfffffe000046fab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000046fab0That is far too low-level for it to be pfSense. It's in interrupt handling.
Nothing noteworthy in the message buffer either:
Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x360 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e785f7 stack pointer = 0x0:0xfffffe000046f9a0 frame pointer = 0x0:0xfffffe000046fa00 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) -
@jimp said in PIMD crash on 2.5.0-devel:
host system
idk, it's not a VM, this is a dedicated machine without any other problem so far, i will reinstall and re-test again when i have the time
-
PIMD seems to cause this same issue on both my routers as well.. Manual or package. It only happens with PIMD active and while Im trying to test by moving multicast traffic. Watchguard XTM5 and XCS units.. 2.4.5rc on one and 2.5 snap on the other..
I was able with the manual install to stop rebooting by some method a few months ago but can't recall what I did at the time. I believe it was by tightening firewall rules to allow only the one multicast frequency I wanted to be able to cross subnets.. Ill do some testing possibly this weekend if it keeps raining here.
It seems that PIMD in general taxes certain units a little. Truthfully I was waiting to see if anyone else had the issue before bringing it up. Figure the Watchguards were just being finicky..
-
Might not be taxing the unit so much as maybe tickling a multicast-related hardware or driver issue.
I still wouldn't say it's a pimd problem, it just happened to be what was introduced when your root problem became apparent.
But sometimes the answer to "doctor, it hurts when I do this" is "don't do that". At least with that combination of hardware.
-
@jimp said in PIMD crash on 2.5.0-devel:
But sometimes the answer to "doctor, it hurts when I do this" is "don't do that". At least with that combination of hardware.
But I like playing basketball on my bad knees doc!!
Yep. I may have to upgrade to better equipment at some point soon. Right now using PIMD is in a testing phase for us. Equipment that hits the sites will not be retired Watchguard gear. Since both these units seem to rely on similar Lanner motherboards..
thanks jimp! -
i made some more test, the problem is with the ix driver
it work if i don't bind on ix interface and bind only on igb interface
so work on intel i350-t4 but crash on my intel x520 -
Hello, as you can read in the development forum "I am fighting" PIMD. It is not necessarily PIMD itself, but the result are "crashes" as soon as I switch an interface off and on and a PIMD not properly working. Today I decided to start googling using keywords from the crash report, and guess what ..... I found a topic arround PIMD started by you. And at the end that in your opinion, it was caused by the x520 ..... It happens to be that a lot of my vlans ..... are x520 based ..... So I am very curieus about the actual situation / your findings !!
Louis
PS I can not bind every thing on 1G interfaces, ......
