Pdsbm-ln2 1U server Lan Ports fail in RC canidate. Using Intel 82573 nic
-
Well I tried again and noticed when using ssh and doing sysctl dev.em.0.nvm=1 I had something appear on my monitor that is on the pfsense firewall. Here is what i seen.. see picture
![2014-12-15 20.50.11.jpg](/public/imported_attachments/1/2014-12-15 20.50.11.jpg)
![2014-12-15 20.50.11.jpg_thumb](/public/imported_attachments/1/2014-12-15 20.50.11.jpg_thumb) -
Hmm, curious. I see that if I do 'sysctl dev.em.0.debug=1'.
Steve
-
So where is the log you mentioned.. I seen nothing in UI https://192.168.1.1/diag_logs.php
And nothing in Dmesg which I posted those also.. Did a search just to make sure I didn't miss it after I scanned both of them for it first time.
-
So if I setup SSH anyone think maybe they see something I missed?
-
Hmm, this is very odd. Seems hard to believe that sysctl command doesn't show anything on the system log when it is referred to specifically for your NIC. :-
Try doing it at the console not via SSH. If I do that at the (serial in my case) console I get:[2.2-RC][root@xtm5.localdomain]/root: sysctl dev.em.0.nvm=1 dev.em.0.nvm: Interface EEPROM Dump: Offset 0x0000 9000 877f 75dc 0420 f746 1090 ffff ffff 0x0010 ffff ffff 026b 0000 8086 10d3 ffff 8758 0x0020 0000 2001 7e74 ffff 1000 00c8 0000 2704 0x0030 6cc9 3150 073e 460b 2d84 0140 f000 0706 -1 -> -1
What do you make of the fact that your initial verbose log shows both em NICs successfully attached after boot? Were they both usable at that point?
@Topper727:em1: Link is up 1000 Mbps Full Duplex
em1: link state changed to UP
pflog0: promiscuous mode enabled
em0: Link is up 1000 Mbps Full Duplex
em0: link state changed to UP
em1: promiscuous mode enabled
em0: promiscuous mode enabled
[2.2-RC]Steve
-
Will try that soon as I can from console. The em0 and em1 you seen working was from the PCI card dual port intel card I have. with older chip on it. the newer chip built on motherboard is one that will not work and stop PCI cards from working if they enabled.
-
Ah, OK. So in the first boot you have disabled both on-board Intel NICs in the BIOS. The second log you don't have additional dual NIC in place.
Neither of those two NIC types are able to dump their ROM? It's probably not the cause of your problem though even if the NICs do turn out to have a bad ROM.
Steve
-
Yes you got it. When dual nic show it is the card with onboard off. the same driver cause just an older chip that runs that pci card for dual ports. just a few versions newer the onboard 2 built in is one that fails and causes any PCI card to fail if those are enabled.. The dump I have not done on local machine yet only through ssh. I will hook back up the monitor and keyboard to do this. I only had 1 key keyboard so I use it for main machine and move there only when need. So Monday if not sooner I will try this when I have more time.
-
Ok here is my dump.. If right at the machine itself in my case USB keyboard and VGA monitor I can get the dump.. But since not able to copy paste like you with the Serial port setup. Please see picture
This is with both built on Lan turned on but only one works
The value is set correctly at least on port that is working .. I can not get status of other one.. But I can make either one work but only one at time.
Value DF I think it said. which bit 1 is set correctly.. AM I right?
![2014-12-30 23.12.15.jpg](/public/imported_attachments/1/2014-12-30 23.12.15.jpg)
![2014-12-30 23.12.15.jpg_thumb](/public/imported_attachments/1/2014-12-30 23.12.15.jpg_thumb) -
Indeed that looks like the correct, so it's not that. :( But at least that's one thing eliminated. :)
Really hard to know what the exact cause of this is at this point. I would have to guess that it's some ACPI interaction that was introduced by the upgrade from FreeBSD 8.3 to 10.1. Assuming that I would try using the various ACPI debug options decsribed here: https://www.freebsd.org/cgi/man.cgi?query=acpi&sektion=4
That is likely to be a long and tedious process that may not in the end actually produce any useful results. :-\Steve
-
I wish some how some way it would start working.
-
This is not a specific pfSense problem. You may have more luck asking for help on the FreeBSD forums. Perhaps someone there has worked around this issue before.
Steve
-
Yes, I found it was since I tried freebsd 10.1 but I did post in forum and nothing back yet.. seems they not as active as pfsense is.. glad you are. I wish I knew way to resinstall drivers
-
https://svnweb.freebsd.org/base?view=revision&revision=269196
This is where they updated the EM driver .. talks about shared code in the update.. Also submitted a bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501
Now the question is. If they fix it in freebsd10.1 will it get into Pfsense and how fast?
Is there a way to downgrade to the driver used in 8.1 till they fix maybe?
I got the older driver but MAKE and PKG_Add are not part of pfense.. PKG_add use to be.. really starting to hate PFSENSE
http://doc.pfsense.org/index.php/Add_Packages_HOWTO_Add_Packages_from_a_shell
-
Drivers are not FreeBSD packages that you can add.
There are no build tools at all in pfSense, including them would only be a security risk.
FreeBSD 10 moved to the pkgng package system.
The driver subsystems changed a lot between 8.3 and 10.1, i'd be surprised if you're able to compile an 8.3 driver against 10.1 source.
It's my belief that it's not the driver anyway but some resource management component.You might try to find exactly which FreeBSD version introduced the issue. Looking at the other bug reports we've referenced in this thread it may have been 9.0 or 9.1.
Steve
-
Solved!
hint.agp.0.disabled=1
in loader.conf fixes the problem. :) -
Huh, how did you find that? Well done. :)
Steve
-
I found by submitting a bug to Intel and someone gave me that to try.. that fixed it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501
-
Ah. Importantly that person was John Baldwin. I'm not going to feel bad not knowing something he does. ;)
Anyway I'm happy a workaround exists and that key FreeBSD people are aware of it.Steve
-
Interestingly, this isn't a em driver bug (as upthread wanted to pursue), but rather a PCI bus issue.