David Lawless wrote: > It only works with the pure Fedora kernel, which we did not > compile. Note that it fails to work with the RHEL 5 kernel, > which we also did not compile. A noticeable difference is that > the RHEL 5 kernel configures the 82575's with MSI-X interrupts.
If the only difference is MSI-X interrupts there are actually a few things you can try to verify if this is in fact the issue. First try loading the Fedora kernel with the option "pci=msi". It seems that on some systems the Fedora kernels disable MSI/MSI-X by default and setting this option may enable MSI/MSI-X interrupts. Second, on any of the other kernels you should be able to compile our OEM driver version 1.2.44.9 and then install the module with the option "IntMode=0,0,0,0". This should force all of the igb ports to use legacy interrupts. > As you see if you read the original message, we have compiled > quite a sample of Kernel.org kernels and tried them. In every > case the instructions that came with the driver were carefully > observed. The 'igb' driver was built both with and without DCA > support--this makes no difference. You have assumed we did not > work this carefully. Let me be absolutely clear that we have. > 'e1000e' drivers compiled by us on a similar system work > perfectly. DCA shouldn't make any difference in this situation. If I am understanding you correctly the issue is that the ethtool shows a link of 1000/Full but states no link is detected. An issue like this would typically be due to the link interrupt not being handled or being masked off. If you could include a dump of /proc/interrupts for the affected system this my also prove useful as it would give us some information on the interrupt configuration of the device. > This is a HP DL160 G5, which is a 1U rack mount server. The two > x16 ports are intended for network and storage devices, not for > graphics. Nobody puts fancy GPUs in 1U rack systems unless they > are to be used as numeric co-processors. The BIOS has no > setting other than a PCI 1 versus PCI 2 indication. It has been > tried both ways--makes no difference. Could you try swapping the dual CX4 and Quad-VT to see if x1 bus width issue follows the slot or the card? This should tell us where the problem lies. If it is a BIOS or hardware issue with the slot then anything plugged into the slot will only report a x1 with the possible exception of graphics cards. > Everything compiles fine except for 'ioatdma.ko' under > 2.6.26 and 2.6.27 kernels. It's obvious that the internal > APIs have changed, since the error is for a structure member > 'ack' that no longer exists. I don't believe the ioatdma provided on our website is currently compatible with 2.6.26/27 kernel api. This is why it is recommended you use the ioatdma provided with these kernels instead of trying to compile the ioatdma driver separately. > We've tried every conceivable combination (in the true > mathematical sense) of hand-compiled versus Fedora 9 and RHEL > 5.2 distribution drivers. Nothing works except the pure > Fedora 9 drivers, the one case where MSI interrupts are disabled. > > It is clear that the driver is immature and has flaws. > This Bugzilla reinforces the perception: > https://bugzilla.redhat.com/show_bug.cgi?id=452289 > > David If you could try the recommendations above it should bring us much closer to understanding the root cause of the issues you are seeing. Also if you could include a dmesg log from one of the non-working OSes instead of Fedora it might help us to resolve the link issue. Thanks, Alex ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
