PIMD crash on 2.5.0-devel

[kiokoman]

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

info.0 textdump.tar.0

[jimp]

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 0xfffffe000046fab0

That 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)

[kiokoman]

@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

[chpalmer]

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..

[jimp]

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.

[chpalmer]

@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!

[kiokoman]

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

[louis2]

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, ......