Incorrect Detection - Intel Pro/1000 MT Dual Port Server NIC
-
Current Supported hardware lists Intel Pro/1000 MT Dual Port as being supported by em(4) drivers. However, I've tested pfSense RC1 with this NIC and it does not work properly. pfSense detects and installs the em(4) driver. At this point pinging the NIC works fine but if you try to access the webadmin, the NIC stop responding to everything including pings. Link status on switch show no signs of a problem. Since I already had m0n0firwall (monofirewall) running well with another of the same NIC, I checked it and found that it was using the sis(4) drivers.
Can someone tell me how to manually set the driver for this NIC? ???
The em(4) driver supports Gigabit Ethernet adapters based on the
Intel 82540, 82541ER, 82541PI, 82542, 82543, 82544, 82545, 82546,
82546EB, 82546GB, 82547 and 82573 controller chips:* Intel PRO/1000 CT Network Connection (82547)
* Intel PRO/1000 F Server Adapter (82543)
* Intel PRO/1000 Gigabit Server Adapter (82542)
* Intel PRO/1000 GT Desktop Adapter (82541PI)
* Intel PRO/1000 MF Dual Port Server Adapter (82546)
* Intel PRO/1000 MF Server Adapter (82545)
* Intel PRO/1000 MF Server Adapter (LX) (82545)
* Intel PRO/1000 MT Desktop Adapter (82540)
* Intel PRO/1000 MT Desktop Adapter (82541)
* Intel PRO/1000 MT Dual Port Server Adapter (82546)
* Intel PRO/1000 MT Quad Port Server Adapter (82546EB)
* Intel PRO/1000 MT Server Adapter (82545)
* Intel PRO/1000 T Desktop Adapter (82544)
* Intel PRO/1000 T Server Adapter (82543)
* Intel PRO/1000 XF Server Adapter (82544)
* Intel PRO/1000 XT Server Adapter (82544)The sis(4) driver supports Silicon Integrated Systems SiS 900 and SiS 7016
based Fast Ethernet adapters and embedded controllers, as well as Fast
Ethernet adapters based on the National Semiconductor DP83815 (MacPhyter)
chip. Supported adapters include:* @Nifty FNECHARD IFC USUP-TX
* MELCO LGY-PCI-TXC
* Netgear FA311-TX (DP83815)
* Netgear FA312-TX (DP83815)
* SiS 630, 635, and 735 motherboard chipsets -
m0n0 defaults to sis(4) and doesn't detect NIC mismatch. Are you sure this nic actually works in m0n0 as a sis(4)? All Intel Pro/1000 cards are detected as em(4) by FreeBSD and should be - sis(4) is a completely different driver for a different chipset.
–Bill
-
At m0n0 you have to run "assign interfaces" from the the shellmenu at first bootup. It has NO autodetection or missmatchdetection (as bill already said). m0n0 comes preconfigured with sis nics.
-
I've been having a similar problem with Intel Server 1000 Base T Nics. I have a system with 2 dual port intel server nics, 2 intel nics on the motherboard, and another intel desktop gig nic. All of them use the em driver
I noticed that every time I tried to make a change to the firewall other than add a nat or firewall rule that the firewall would lock up and stop responding, forcing me to reinstall and reload my configuration file. I logged onto a shell and ran a dmesg | less and learned that my motherboard had assigned the same irq all of my network cards.
I fixed this by turning off all the unnecessary hardware in the bios and then selecting the manually assign resources on the pci setup screen in the bios. Upon reboot, each network port had a different irq and I/O range assigned to it, and the lockups went away. Unfortunately, I spent two sleepless nights trying to find the problem before it dawned on me.
-
Yes even in this age of PnP 'nirvana', or sometimes hell, shared IRQ's are still BAADDDD. I fail to see why we need should be forced to use shared IRQ's on systems with 4 NIC's no use for parallel or more than one serial port, and not even a use for PS2 irq 12 in most cases. We have way more IRQ's than are necessary yet, brain dead designers force 4+ devices onto the same PCI slot and IRQ and wonder why things don't work properly.
I still have to manually assign IRQ's to this day. Ever since Winexploader '95 graced us with it's presence, we've been dealing with IRQ's. I wish we could go back to the good ole' days where things had jumpers and it just plain didn't work if you had things on the same IRQ. At least then it was a 'it's working' or 'it's not working' condition. Flakiness is just plain wrong!
-
Yes even in this age of PnP 'nirvana', or sometimes hell, shared IRQ's are still BAADDDD. I fail to see why we need should be forced to use shared IRQ's on systems with 4 NIC's no use for parallel or more than one serial port, and not even a use for PS2 irq 12 in most cases. We have way more IRQ's than are necessary yet, brain dead designers force 4+ devices onto the same PCI slot and IRQ and wonder why things don't work properly.
I still have to manually assign IRQ's to this day. Ever since Winexploader '95 graced us with it's presence, we've been dealing with IRQ's. I wish we could go back to the good ole' days where things had jumpers and it just plain didn't work if you had things on the same IRQ. At least then it was a 'it's working' or 'it's not working' condition. Flakiness is just plain wrong!
Here here! Very well said!
-
dipswitches haven't been bad either ;D