Hi Michel,
I know it's been a while since we last chatted about this, but I took your
recommendation at that time and bought 4 of these cards from the US (I'm in
Australia).
When inserting the cards into 2 newly built SL4 servers, Linux picks them up
and configures the e1000 module without issues.
lspci shows:
00:0e.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller
(rev 02)
and
00:09.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller
(rev 02)
on both servers, and ethtool shows:
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
on both servers.
However, I've been testing "ping" on these cards under SL4 without any
success (a ping from the local host works but not from the remote host).
I inserted one card in each of two servers, and hooked them up via a cross-
over cable. They autonegotiate to 1000mbps FD, but they cannot communicate
with each other at all (they link fine, just cannot ping each other). When I
try adn ping from the private subnet I've assigned each card, the only
responses I get from the cards are:
kernel: NETDEV WATCHDOG: eth1: transmit timed out
kernel: e1000: eth1: e1000_watchdog: NIC Link is Down
kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
every few seconds. If I stop the pings, they sit there idle and happy
without resetting the interfaces at all, only when I try and transmit data
(ping), I get the "NETDEV WATCHDOG" errors.
Last night I was trouble-shooting this problem for about 6 hours, trying
everything I could think of, different speeds and duplex settings, even
downloading the latest intel drivers for these cards and compiling them as
modules and trying them, still no go (although the new driver - e1000-
6.0.54.tar.gz - got rid of the "NETDEV WATCHDOG" errors, I still couldn't
ping the interfaces).
I used the intel diag1000 tools off the cd which accompanied the cards to
test the cards from dos. All test passed fine and even the continuous
network tests with one setup as a responder and the other running the
network test (and vice versa), but under Linux a total no go.
When running ethtool's offline test, on one server I get:
# ethtool -t eth1 offline
The test result is FAIL
The test extra info:
Register test (offline) 0
Eeprom test (offline) 0
Interrupt test (offline) 4
Loopback test (offline) 0
Link test (on/offline) 0
(an SMP server)
on the other server I get:
# ethtool -t eth1 offline
The test result is PASS
The test extra info:
Register test (offline) 0
Eeprom test (offline) 0
Interrupt test (offline) 0
Loopback test (offline) 0
Link test (on/offline) 0
(a UP server)
The "Interrupt test (offline) 4" on the first server concerned me
but I tried everything I could think of from BIOS changes etc but could not
get it corrected.
I booted both servers with "noapic" and "acpi=off" as some others suggested
from googling, but the same results above.
I tried configuring the "InterruptThrottleRate" in /etc/modprobe.conf as
suggested by Intel in:
ftp://aiedownload.intel.com/df-support/2897/ENG/README.txt
as they seemed to recognise this NETDEV problem, but again no go.
So basically, from what I've seen so far, I just can't use these cards under
SL4.
Today I'm just going to try connecting them to my 100Mbps FD switch and see
if they at least work like that, but I'm really not that hopeful.
Michael.
> If you want 32-bit pci Nic's, I'd suggest the Intel Pro/1000 MT.
>
> It's what I run in this particular desktop system as well as several
> others. In my servers (~50) I have all 64-bit PCI-X broadcom nic's
> integrated on the boards.
>
> They both seem to work quite well.
>
> Hope this helps.
>
> Michael
>
> On Tue, 2005-02-15 at 10:19 +1000, Michael Mansour wrote:
> > Hi Michael,
> >
> > Is there any particular model of Intel gigabit card you recommend?
> >
> > I've spoken to my supplier and they say they'll take back the cards I
bought
> > and swap them for Intel, but would like to know a model so I don't have
to
> > make this same mistake again.
> >
> > Thanks.
> >
> > Michael.
> >
> > > Well the first thing I'd say is that the realtek chipset's are terrible
> > > if you really want performance. They don't do any packet header
> > > processing or other tcp hardware offloading, causing your CPU to take
> > > the brunt of the packet load (with gigabit this is bad).
> > >
> > > I would recommend Broadcom or Intel based gigabit cards.
> > >
> > > Regardless of this fact, mii-tool doesn't support reading out gigabit
> > > link status. It'll give you a link up status with 100FD for 1000FD
cards
> > > linked at 1000FD with flow control enabled.
> > >
> > > I know it at least reports on the broadcom and intel based cards
> > > with a link up status.
> > >
> > > Otherwise, I think you might need to find another tool to get real link
> > > status out of a gigabit nic.
> > >
> > > On Tue, 2005-02-15 at 09:32 +1000, Michael Mansour wrote:
> > > > Hi,
> > > >
> > > > I've just purchased some Netgear 1gigabit ethernet cards and to my
> > > > dissapointment mii-tool couldn't be used to query them, even though
the
> > linux
> > > > kernel has no issues with using them.
> > > >
> > > > I run cluster software with SL303 which uses mii-tool to do link
level
> > > > checking etc... so my question is, which 1gigabit cards work
correctly
> > with
> > > > SL303 and mii-tool? so that I get output similar to the following:
> > > >
> > > > [root@anaconda root]# mii-tool
> > > > eth0: negotiated 100baseTx-HD, link ok
> > > > eth1: negotiated 100baseTx-HD, link ok
> > > > SIOCGMIIPHY on 'eth2' failed: Operation not supported
> > > >
> > > > note: eth2 is the Netgear card (which uses a Realtek chip), the
other two
> > are
> > > > just standard Realtek PCI cards.
> > > >
> > > > Thanks.
> > > >
> > > > Michael.
> > ------- End of Original Message -------
------- End of Original Message -------
|
