Em2: watchdog timeout – resetting, plz i need help
-
I gave up intel nic, and bought a HP NC382T nic Broadcom 5709, my god! It is the same problem! What can this be? Did I data traffic is not supported by pfSense? :'(
bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7273): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN
bce0: link state changed to UP
bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7273): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN
bce0: link state changed to UP
bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7273): Watchdog timeout occurred, resetting!
bce0: 2 link states coalesced
bce0: link state changed to UP
bce0: link state changed to DOWN
bce0: link state changed to UP
bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7273): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN
bce0: link state changed to UP
bce0: /usr/pfSensesrc/src/sys/dev/bce/if_bce.c(7273): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN -
discovered something very important, if I disable pf (pfctl-d) the error watchdog timetout ends! I'm almost to the solution of the problem, which can be guys?
-
I found the problem, strangely when I activate filtering on the bridge members (# sysctl net.link.bridge.pfil_member: 1) errors watchdog timeout end! :o I would not want to use filtering bridge members as the firewall rules are more complex, does anyone know how to solve this?
-
anyone ? :'(
-
I'm running a bridge on a wired interface and a WiFi interface in pfSense 2.0.1 with filtering on the bridge and I don't see watchdog timeout errors. Therefore I don't think what you are seeing is something tied to filtering on a bridge or its members.
I second the suggestion: @SunCatalyst:
have you Tried any of the Pfsense 2.1-Beta releases to see if things are any better?
pfSense 2.1 builds have much more up to date device drivers than the 2.0.x builds.
-
I'm running a bridge on a wired interface and a WiFi interface in pfSense 2.0.1 with filtering on the bridge and I don't see watchdog timeout errors. Therefore I don't think what you are seeing is something tied to filtering on a bridge or its members.
I second the suggestion: @SunCatalyst:
have you Tried any of the Pfsense 2.1-Beta releases to see if things are any better?
pfSense 2.1 builds have much more up to date device drivers than the 2.0.x builds.
how not? if I disable pf (pfctl-d) or add filtering on bridge members the problem goes away?
I tested version 2.0.3 and 2.1RC0 same problems … -
bump
-
Disabling pf altogether will dramatically reduce the loading on the CPU which might explain why you don't see timeouts in that case.
Leaving filtering on the bridge members is harder to explain. Perhaps in doing that you are better able to take advantage of hardware off loading features on the NICs. Since the bridge interface is done in software it has no off loading. This could result in a higher cpu load and eventual timeouts. That's speculation though.
Neither of those seems very likely as your i5 should have no problems. Since you have seen the same problem across different NICs it does appear that some feature of your motherboard/chipset is not working well with FreeBSD. It seems that maybe your board/cpu is not servicing interrupts either at all or fast enough under some conditions. I would probably try disabling MSI or MSI-X to see if that effects the situation at all.
hw.pci.enable_msi=0 hw.pci.enable_msix=0If it is some incompatibility between FreeBSD and that board someone else will probably have already seen it.
Steve
Edit: I assume this is you? http://freebsd.1045724.n5.nabble.com/em2-watchdog-timeout-resetting-td5813842.html
-
1-I am using filter in bridge members, was the only solution I found to the problem ….
I used another motherboard with different chipset and has the same problem, I think pfsense can not process a trunk link with a large number of VLANs... my opinion.
2 - yes I am :) -
There have been reports of using, successfully, 1000+ VLANs with pfSense so it's not a problem with that directly. Perhaps some combination of a large number or VLANs and interface bridging? :-
Did you try any of the suggestions from the FreeBSD lists?Steve
