In addition to what Alex has said the BZ reference
(https://bugzilla.redhat.com/show_bug.cgi?id=452289) does not apply at
all to this issue as it referes to RHEL and not Fedora.  It is also a BZ
that is open to make sure that the latest version (not immature) is
included in relevant RHEL update release.  Having open bugzillas is for
tracking purposes and in this case, not anything to do with known issues
with the driver.  The BZ is to track new HW enablement for the update
release.


Cheers,
John
-----------------------------------------------------------
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.", Benjamin
Franklin 1755 
 

>-----Original Message-----
>From: Duyck, Alexander H 
>Sent: Monday, October 13, 2008 11:01 AM
>To: David Lawless
>Cc: e1000-devel@lists.sourceforge.net; Ronciak, John
>Subject: Re: [E1000-devel] IGB driver 1.2.44.9 problem
>
>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
>

-------------------------------------------------------------------------
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

Reply via email to