On Apr 6, 2015, at 2:11 PM, Eric Hamilton <eric.hamil...@harmonicinc.com> wrote: > > Thanks again, Mark. We are already using a 64-bit kernel: > > [root@hbcb ~]# uname -a > Linux hbcb 2.6.18-128.6om #1 SMP PREEMPT Fri Mar 27 00:39:10 PST 2015 x86_64 > x86_64 x86_64 GNU/Linux
Excellent. Well, at least a lot better than a 32-bit kernel for many reasons. > This is essentially a 2.6.18-128.el5 kernel plus a few patches. There have > been many improvements to the PCI subsystem since then and it appears that > either there was still something in the old kernel's PCI code that couldn't > handle 64-bit BAR addresses, that there's some other thing in Wildcat Pass > that the old kernel can't handle in conjunction with 64-bit PCI addresses, or > there's something else going on. > > If there's something obvious to do to fix this in software, I'm interested. > But since our particular need doesn't place heavy pressure on PCI config > address space and this is for an appliance use, I think we can live with the > BIOS setting for now. Rather than doing much more debugging of PCI on > 2.6.18, it'll be better to spend that effort getting to a modern kernel. > > If anybody is interested in understanding why ixgbe for the X520-SR2 fails on > Wildcat Pass running a 2.6.18 era kernel, I've gone ahead and attached the > lspci -vvv output for one port of the card in three cases: > * Working: Booting old kernel with ixgbe.ko hidden with "Memory Mapped I/O > above 4 GB" == <Disabled> > * Broken: Booting old kernel with ixgbe.ko hidden with "Memory Mapped I/O > above 4 GB" == <Enabled> > * Centos 7: Booting and working with Centos 7 with "Memory Mapped I/O > above 4 GB" == <Enabled> > > A diff shows that the only differences between Working and Broken are the > addresses of Region 0 and Region 4. I have to admit that I have very little interest in tracking down that issue in the older kernel - and I would expect that fixing it would likely involve changes that would be more disruptive than simply moving to a newer kernel. However, if you had been running a 32-bit kernel I would have had a lot of concerns about that because 10G Ethernet tends to consume enough kernel memory to cause problems for 32-bit kernels in some cases. If forcing the BIOS to allocate the BARs in the first 4G works for you, then that is the best solution for you on that platform with that kernel. I'm sure you have encountered the exact reason why that BIOS option is there - it is not there for no reason. -- Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
