Silcom PEG6I (82571EB Based)
-
Here are the commands you asked for wallabybob, let me know if you want anything else. These messages are a bit cryptic to me, but i will look them up later. Im curious to know what the output means. My *nix is a bit weak.
$ pciconf -r pci0:0:28:0 0:0x3f 27d08086 00100104 06040001 00810010 00000000 00000000 00010100 200000f0 0000fff0 0001fff1 00000000 00000000 00000000 00000040 00000000 00060110 $ pciconf -r pci0:0:28:4 0:0x3f 27e08086 00100107 06040001 00810010 00000000 00000000 00020200 2000d0d0 fea0fea0 fde1fde1 00000000 00000000 00000000 00000040 00000000 00060110 $ pciconf -r pci0:0:28:5 0:0x3f 27e28086 00100107 06040001 00810010 00000000 00000000 00030300 2000e0e0 feb0feb0 fdf1fdf1 00000000 00000000 00000000 00000040 00000000 00060211 -
The Silcom PEG6I has a PLX 8715 PCI Express bridge which appears in the PCI device tree as one "upstream" (closest to the CPU) PCI bridge with three downstream PCI bridges. Each of the downstream PCI bridges is connected to a single Intel NIC chip with two PCI functions, each PCI function providing a single Ethernet interface. Each of the downstream PCI bridges requires a distinct PCI bus number so the devices downstream of them can be addressed. The upstream bridge therefore requires at least four downstream bus numbers (one for each of the downstream bridges and one for the bus interconnecting the bridges).
From the FreeBSD startup report of its walk of the PCI device tree we see there are three PCI bridges, two of which are used to connect to the board LANs leaving the bridge at device=28 function=0 for interfacing to the expansion slot device, in this case a Silcom PEG6I. A dump of the PCI configuration registers of this bridge shows:
$ pciconf -r pci0:0:28:0 0:0x3f
27d08086 00100104 06040001 00810010
00000000 00000000 00010100 200000f0
0000fff0 0001fff1 00000000 00000000
00000000 00000040 00000000 00060110The byte at offset 0x14 is 0, the upstream bus number of the bridge, the byte at offset 0x15 is 0x01, the first secondary (downstream) bus number and the byte at offset 16 is 0x01, the maximum secondary bus number. Hence this bridge has been allocated insufficient secondary bus numbers to allow access to the NICs on the card. The bridge also has its memory window base and top registers and i/o window base and top registers programmed to prevent memory and i/o register access to downstream devices.
FreeBSD is not a plug and play operating system; that is FreeBSD relies on the BIOS to perform PCI device resource allocation.
The failure of the BIOS to allocate PCI resources to devices downstream of a bridge on an expansion card makes this otherwise attractive motherboard unsuitable for some users of the FreeBSD operating system and the pfSense package.–-----------------------------------------------------------------------------
I hope the above explanation has sufficient technical detail or the people supporting the BIOS on the motherboard without being too technical for the well informed reader. -
I hope the above explanation has sufficient technical detail or the people supporting the BIOS on the motherboard without being too technical for the well informed reader.
Spot on I'd say, very informative. :)
Steve
-
Good explination Wallabybob. Do you think this could be fixed via a BIOS update from SM or its is a phy limitation of the board itself?
-
Do you think this could be fixed via a BIOS update from SM or its is a phy limitation of the board itself?
A BIOS update would appear to be necessary to fix this. I don't know enough about the hardware to say if it would be sufficient. I have seen reports hinting of restrictions placed on Atom based boards (e.g. no PCI-Express slots on early Atom boards, at most one expansion slot etc) so there may be a hardware limitation but I read in this thread that all the NICs had been recognised when running Linux but maybe it wasn't clear that it was Linux running on this type of board. If Linux running on this board finds all the NICs and can drive them then there is no limitation in the hardware that would stop FreeBSD finding all the NICs and driving them - it just needs the BIOS to initialise the PCI bridges (both in the chipset and on the card) so FreeBSD can find the NICs when it walks the PCI device tree.
Frankly, I think it is poor form to provide an expansion slot and be silent about the fact that certain combinations of cards and operating systems won't work in the slot. There is a precedent with 4GB memory - plenty of motherboard manufacturers say you can't use more than about 3GB of RAM with 32 bit Operating Systems and are quite upfront about max size of memory.
-
Has any of this code made it into 8.3 I wonder:
http://lists.freebsd.org/pipermail/freebsd-arch/2011-April/011268.html
It seems to be addressing this issue. Or at least a similar one. ;)Steve
-
Has any of this code made it into 8.3 I wonder:
http://lists.freebsd.org/pipermail/freebsd-arch/2011-April/011268.html
It seems to be addressing this issue. Or at least a similar one. ;)Thanks for the reference. After reading the whole thread it does look as if it addresses at least a similar issue. I suggest trying a pfSense 2.1 snapshot build. If that isn't very convenient you could send an email to John Baldwin referencing the thread and this discussion and ask if the code is in FreeBSD 8.3 and does it address this issue.
-
Look like it made it into the code base some time ago. A while before the 8.3 branch point.
Steve
-
Some time this week I will try a 2.1 x64 snapshot and see what happens.
-
Finally got around to trying the latest 2.1 x64 snapshot, but still no luck with the card. I also tried Ubuntu 11.10 x64 live and it would not detect the card. Seems to be more of a BIOS issue, maybe i will write up a support email to supermicro about the PEG6i and see what happens.
Thanks for your help wallabybob
-
Since this probably won't be fixed in a timely manner, anyone have a recommendation for another 4-6 port Intel-chipset NIC that is compatible with the SuperMicro Atom boards?
And if anyone has one they want to sell, I'll trade the PEG6I for it.
-
It might be worth asking SuperMicro if any multi-port boards with Intel NICs are supported on their Atom motherboards running FreeBSD.
It might be worth asking Silcom if the PEG6I is supported on any SuperMicro Atom motherboards running FreeBSD.
-
I sent SuperMicro some emails with the above questions a few weeks ago, but no responses >:(
I'm hoping someone here has added a 2-4 port NIC to a SuperMicro Atom with success and can recommend it here
-
Erack
I'm using a DELL G174P 2port Intel card. The version i have is using the newer Intel Pro ET chip. There are two version of this card from what I could tell, newer Intel Pro ET has no heatsink on the chip and older PT has a heat sink. I have been using the card as my LAN interface for several months with multiple vlans and haven't noticed any issues yet.
This is what pfSense 2.0.1 detected the card as.
igb0: <intel(r) 1000="" pro="" network="" connection="" version="" -="" 2.2.3="">port 0xcc00-0xcc1f mem 0xfe9e0000-0xfe9fffff,0xfe400000-0xfe7fffff,0xfe9dc000-0xfe9dffff irq 16 at device 0.0 on pci1 igb0: Using MSIX interrupts with 5 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb1: <intel(r) 1000="" pro="" network="" connection="" version="" -="" 2.2.3="">port 0xc880-0xc89f mem 0xfe9a0000-0xfe9bffff,0xfe000000-0xfe3fffff,0xfe9d8000-0xfe9dbfff irq 17 at device 0.1 on pci1 igb1: Using MSIX interrupts with 5 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD]</intel(r)></intel(r)> -
Since this probably won't be fixed in a timely manner, anyone have a recommendation for another 4-6 port Intel-chipset NIC that is compatible with the SuperMicro Atom boards?
And if anyone has one they want to sell, I'll trade the PEG6I for it.
The post from Gluon99 reminded me that I have seen hints of Intel chips packing 4 NICs into the one chip. Investigations a few years ago suggested some of the Intel 2 port and 4 port boards might have all the NICs in a single chip. I suspect the absence of a bridge will enable such boards to work with the Super Micro motherboards.
