Bug #3481
closed
Run-Away processing with hme NICs
0%
Description
Subsequent to posting an issue to the mailing list (issue documented at http://www.derman.com/pfSense-Run-Away-Issue) and getting the following response from Jim Pingle (thanks, Jim):
---
Try pfSense 2.1.1. There were some issues with link cycling in certain cases that you might be hitting which were fixed on 2.1.1.
---
I did a lengthy series of tests. After still getting the same run-away behavior even after reducing the config to a level where I'd be able to send it to someone, I realized I'd not tried switching out the kind of NIC used for the WAN port (though I had tested 2 different NICs in 2 different machines).
Short story is that it appears to be related to using an hme NIC for a monitored interface. See the above web page for what I think I know about this issue.
If you're unable to replicate the issue and/or want me to try something, contact me via the contact form on our/that web site and I'll do what I can to help.
I made backups as I was testing so I can also get you a backup of the most-reduced config I tested.
Updated by Chris Buechler about 10 years ago
- Status changed from New to Feedback
seems likely to be driver-specific, can you test with a different type of NIC to confirm or deny that?
Updated by B. Derman about 10 years ago
Chris:
Per the 3rd bullet on the indicated web page "... in all cases, simply switching the interface to a vr, de, or rl NIC port instead of an hme NIC port avoided the run-away behavior"
Those (vr, de, & rl) are the only other kind of NICs I have laying around, but I agree that it does seem to be an issue only when using an hme NIC with my config.
FWIW, I think you and the team do very nice work and produce a very professional product (and I don't often say such things) ... something y'all should be proud of. Many kudos.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Needs Patch
ah thanks, I didn't check the link. Driver issues are outside our control. It might be fixed in FreeBSD 10.0, though not sure a driver that old gets much attention anymore. It'll need to be fixed upstream for us to have a fix.
Updated by Volker Kuhlmann about 10 years ago
I have this same problem. I am fairly certain it did not occur on pfsense 2.0.x (the last stable before 2.1).
When the interface goes down once because the corresponding device is turned off (printer, wifi AP) or presumably simply unplugged, on re-plug the interface does a yoyo with php processes spiralling out of control.
killall php gives relief for about 2 minutes. A reboot is required.
This applies to a Sun 4-port Ethernet PCI card with the hme0/hme1/hme2/hme3 driver.
The run-away behaviour does not occur with the rl driver.
It is ironic that freebsd dies on solid, reliable hardware while realtek (generally considered) junk works fine...
The reason I need to use the Sun 4-port card is to get enough ports into the pfsense system so I am a bit stuck now.
Because of the memory run-away occurring with php processes I am not entirely convinced it is not a pfsense bug afterall. Would a person with enough insight be able to comment?
Thanks for a professional firewall!
Updated by Chris Buechler about 10 years ago
It's a hme driver problem, the PHP that gets kicked off repeatedly is a symptom of the underlying driver issue. We have nothing to do with the hme driver. If it's still an issue in 2.2, you'll have to replicate on stock FreeBSD and report upstream.