Re: [E1000-devel] dual port PRO 1000 PT working at 10 Mbps
To answer myself, the card appears to have been the problem, we replaced it and it works fine for the time being. On Tue, 18 May 2010, Dimitris Zilaskos wrote: > > Dear all, > > First of all apologies if this list is not appropriate for such questions. > > We have a number of IBM System x3550 servers equiped with dual port PRO > 1000 PT network cards. > > 13:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet > Controll > er (rev 06) > Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter > > Some of them don't get along with all our switches. In particular with our > extreme networks summit x24T, cisco3750 and dell 6224. The link stays in > 10 Mbps no matter what we try (cable changes, port changes, forcing port > speed with ethtool or from switch settings, different rhel5 kernels, > downloading driver and compiling it from intel website). When they are > connected to the ports, the led flash about 3-4 times and the speed gets > at 10 Mbps. However the same card will connect with 1 Gbps to a dell 5424 > switch. > > Here is the ethtool output for one troubled system. eth0 is connected to > the extreme networks switch, eth1 to the cisco one. Connecting eth0 to > cisco with different cables does not help. However it worked for eth1 > which had the same issue with the extreme switch, but linked fine at 1 > Gbps with the cisco3750. > > Settings for eth0: > 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: 10Mb/s > Duplex: Full > Port: Twisted Pair > PHYAD: 1 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: d > Wake-on: d > Current message level: 0x0001 (1) > Link detected: yes > 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: 1 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: d > Wake-on: d > Current message level: 0x0001 (1) > Link detected: yes > > What can I try to resolve this problem? Are the cards just faulty (the > problem is present to 4 identical nodes out of a total of 8). > -- = Dimitris Zilaskos GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece Tel: +302310998988 Fax: +302310994309 http://www.grid.auth.gr = -- ___ 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
Re: [E1000-devel] [PATCH net-next] ixgbe: return error in set_rar when index out of range
On Tue, May 18, 2010 at 08:34, Shirley Ma wrote:
> Return -1 when set_rar index is out of range
>
> Signed-off-by: Shirley Ma
> ---
>
> drivers/net/ixgbe/ixgbe_common.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
I think this should use IXGBE_ERR_ instead and there is another
spot where this could be used. Instead I propose this patch
instead...
ixgbe: return IXGBE_ERR_RAR_INDEX when out of range
From: Jeff Kirsher
Based on patch from Shirley Ma
Return IXGBE_ERR_RAR_INDEX when RAR index is out of range, instead of
returning IXGBE_SUCCESS.
Signed-off-by: Jeff Kirsher
Acked-by: Don Skidmore
---
drivers/net/ixgbe/ixgbe_common.c |2 ++
drivers/net/ixgbe/ixgbe_type.h |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c b/drivers/net/ixgbe/ixgbe_common.c
index 1159d91..9595b1b 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1188,6 +1188,7 @@ s32 ixgbe_set_rar_generic(struct ixgbe_hw *hw,
u32 index, u8 *addr, u32 vmdq,
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return IXGBE_ERR_RAR_INDEX;
}
return 0;
@@ -1219,6 +1220,7 @@ s32 ixgbe_clear_rar_generic(struct ixgbe_hw *hw,
u32 index)
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return IXGBE_ERR_RAR_INDEX;
}
/* clear VMDq pool/queue selection for this RAR */
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index bd69196..37d2807 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2600,6 +2600,7 @@ struct ixgbe_info {
#define IXGBE_ERR_FDIR_REINIT_FAILED-23
#define IXGBE_ERR_EEPROM_VERSION-24
#define IXGBE_ERR_NO_SPACE -25
+#define IXGBE_ERR_RAR_INDEX -26
#define IXGBE_NOT_IMPLEMENTED 0x7FFF
#endif /* _IXGBE_TYPE_H_ */
--
___
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
Re: [E1000-devel] carrier detection issues at 10GB on XAUI with ixgbe driver on 2.6.27 x86 board
On 05/18/2010 04:01 PM, Waskiewicz Jr, Peter P wrote: > I agree with Jesse, we need an EEPROM dump. Also, which driver version > are you using, and what is the device ID of the board you're using? > There are a few designs in the field using XAUI, just want to see > which one you're using. I sent the EEPROM dump in my previous message. The driver version shows up as "2.0.72.4-NAPI". The device ID is 10fc, or IXGBE_DEV_ID_82599_XAUI_LOM. Chris -- ___ 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
Re: [E1000-devel] carrier detection issues at 10GB on XAUI with ixgbe driver on 2.6.27 x86 board
I agree with Jesse, we need an EEPROM dump. Also, which driver version are you using, and what is the device ID of the board you're using? There are a few designs in the field using XAUI, just want to see which one you're using. -PJ Sent from my iPhone On May 18, 2010, at 2:08 PM, "Brandeburg, Jesse" wrote: > On Tue, 2010-05-18 at 13:53 -0700, Chris Friesen wrote: >> I'm seeing some strange behaviour with an 82599 using XAUI at 10GB. >> Intermittently we get a scenario where it seems to get stuck in the >> following loop: >> >> link detected as up >> 40-45ms delay >> link detected as down >> 2 sec delay >> >> The following is a detailed timeline for one specific event. >> Timestamps >> are in microseconds: >> >> 762926422: link tests as down, LINKS register 0x34480100 >> (100ms gap) >> 763026224: audit detects link up, LINKS register 0x744bef80 >> 763026254: receive link state change interrupt via pci message, >> triggers >> watchdog to run (but it's already running) >> 763026260: link up message printed to log stream >> 763026383: link tests as up, LINKS register 0x744bef80 >> (45ms gap) >> 763071115: receive link state change interrupt via pci message >> 763071134: link tests as down, LINKS register 0x34480f00 >> 763170935: link tests as down, LINKS register 0x34480100 >> >> Basically, as far as I can tell the LINKS register values match >> what we >> would expect to see if the far end was going up and down. However, >> the >> logs we have from the switch card (which admittedly don't give >> register-level information) don't show it bouncing the link up and >> down >> this fast. >> >> Any ideas what might be happening here? > > None that immediately come to mind, I forwarded this to our hardware > engineering however to take a look. > >> To save some time looking at the datasheet, the relevent bits in the >> LINKS register are interpreted as follows. For the 2nd and 3rd values >> I'll only give the deltas against the previous one. >> >> 744bef80: >> link is up >> 10G align status good >> 10G lane sync status good all lanes >> signal detected on all four lanes of 10G parallel >> link status is up >> >> 34480f00: >> link not up >> 10G align status failed >> 10g parallel lane sync status is failed >> link status is down >> >> 34480100: >> signal detected only on lane 0 of 10G parallel (lanes 1/2/3 no signal >> detected) >> >> >> So basically we start out with no signal, then after 100ms we >> transition >> to the proper register values for a normal "up" link, then 45ms >> later we >> lose the alignment status (but still have good lane sync status), and >> finally 100ms later we lose signal detect on 3 of the 4 lanes. > > Does the link eventually come up? We may need to get an eeprom dump > from the 82599 part you're working on as well. > > ethtool -e ethX > > should suffice. > > > -- > Jesse Brandeburg > This email sent via Evolution, powered by Linux > -- ___ 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
Re: [E1000-devel] carrier detection issues at 10GB on XAUI with ixgbe driver on 2.6.27 x86 board
On 05/18/2010 03:08 PM, Jesse Brandeburg wrote: > On Tue, 2010-05-18 at 13:53 -0700, Chris Friesen wrote: >> Any ideas what might be happening here? > > None that immediately come to mind, I forwarded this to our hardware > engineering however to take a look. Much appreciated. > Does the link eventually come up? We may need to get an eeprom dump > from the 82599 part you're working on as well. > > ethtool -e ethX > > should suffice. The problem is intermittent (most of the time it works fine) but once it gets into this state it seems to stay stuck. I've had it remain stuck over a weekend, for instance. Rebooting the blade clears it up...I'm not sure about doing down/up on the link, I forgot to try it when I reproduced it. The board in question is an atca application blade. Each board has a 10Gbps link to each of two switch cards. The problem shows up most frequently in a stress-test chassis where we have a dozen or so blades of this type. When we reboot the switch card, frequently one of the 82599 links will end up in this link bounce state. I was also able to reproduce it by rebooting one of the application blades several dozen times. I've included the eeprom dump from one of the links down below. Lastly, while I've got your attention, I'd like to refer you to a message I sent to the e1000_devel list a while back. (http://sourceforge.net/mailarchive/message.php?msg_name=4BD9C39C.3050804%40nortel.com) I was basically asking why we try the smartspeed autonegotiation stuff even though it's hardcoded to XAUI and autonegotiation is disabled. It seems like we could avoid all those retries and delays since we know up front that they're going to fail. Thanks for the help, Chris Friesen Offset Values -- -- 0x 40 06 00 00 00 00 40 00 6d 00 fd 00 8d 01 a3 01 0x0010 a9 01 af 01 b7 01 bf 01 c7 01 cf 01 09 02 ff ff 0x0020 00 04 ff ff ff ff ff ff ff ff ff ff ff ff 48 02 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0050 ff ff 94 00 ff ff ff ff ff ff 01 00 bd 18 ff ff 0x0060 00 01 00 40 15 21 03 40 00 01 00 40 ff ff 38 05 0x0070 00 00 ff ff ff ff ff ff ff ff ff ff ff ff b2 4f 0x0080 2c 00 94 00 00 00 96 00 06 00 00 00 00 00 00 00 0x0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00d0 00 00 00 00 00 00 00 00 00 00 8f 00 00 01 01 08 0x00e0 40 87 01 01 00 21 10 76 50 81 00 a3 02 01 8c 0b 0x00f0 50 43 03 01 01 20 23 21 00 22 04 01 66 04 7e 06 0x0100 73 45 88 5c 10 78 30 79 04 95 3b 97 c0 98 01 cb 0x0110 33 cc 33 cd 33 ce 33 cf 07 01 d4 36 08 01 70 02 0x0120 03 4c 0a 01 00 11 00 12 c8 17 00 18 c8 1a 00 1b 0x0130 80 1d 00 1e c8 20 00 21 c8 23 00 24 c8 26 00 27 0x0140 80 29 00 2a 0b 01 00 71 0d 01 80 6e 80 70 00 01 0x0150 40 87 ff aa 7f b1 07 b6 03 01 04 15 00 16 35 17 0x0160 0c 18 00 19 3f 1a 12 1b 00 01 00 01 00 01 00 01 0x0170 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x0180 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x0190 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01a0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01b0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01c0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01d0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01e0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x01f0 00 01 00 01 00 01 00 01 00 01 8f 00 00 01 01 08 0x0200 40 87 01 01 00 21 10 76 50 81 00 a3 02 01 8c 0b 0x0210 50 43 03 01 01 20 23 21 02 22 04 01 66 04 7e 06 0x0220 73 45 88 5c 10 78 30 79 04 95 3b 97 c0 98 01 cb 0x0230 33 cc 33 cd 33 ce 33 cf 07 01 d4 36 08 01 70 02 0x0240 03 4c 0a 01 00 11 00 12 c8 17 00 18 c8 1a 00 1b 0x0250 80 1d 00 1e c8 20 00 21 c8 23 00 24 c8 26 00 27 0x0260 80 29 00 2a 0b 01 00 71 0d 01 80 6e 80 70 00 01 0x0270 40 87 ff aa 7f b1 07 b6 03 01 04 15 00 16 35 17 0x0280 0c 18 00 19 3f 1a 12 1b 00 01 00 01 00 01 00 01 0x0290 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02a0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02b0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02c0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02d0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02e0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x02f0 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x0300 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 0x0310 00 01 00 01 00 01 00 01 00 01 15 00 3b bf ba 01 0x0320 07 00
Re: [E1000-devel] carrier detection issues at 10GB on XAUI with ixgbe driver on 2.6.27 x86 board
On Tue, 2010-05-18 at 13:53 -0700, Chris Friesen wrote: > I'm seeing some strange behaviour with an 82599 using XAUI at 10GB. > Intermittently we get a scenario where it seems to get stuck in the > following loop: > > link detected as up > 40-45ms delay > link detected as down > 2 sec delay > > The following is a detailed timeline for one specific event. Timestamps > are in microseconds: > > 762926422: link tests as down, LINKS register 0x34480100 > (100ms gap) > 763026224: audit detects link up, LINKS register 0x744bef80 > 763026254: receive link state change interrupt via pci message, triggers > watchdog to run (but it's already running) > 763026260: link up message printed to log stream > 763026383: link tests as up, LINKS register 0x744bef80 > (45ms gap) > 763071115: receive link state change interrupt via pci message > 763071134: link tests as down, LINKS register 0x34480f00 > 763170935: link tests as down, LINKS register 0x34480100 > > Basically, as far as I can tell the LINKS register values match what we > would expect to see if the far end was going up and down. However, the > logs we have from the switch card (which admittedly don't give > register-level information) don't show it bouncing the link up and down > this fast. > > Any ideas what might be happening here? None that immediately come to mind, I forwarded this to our hardware engineering however to take a look. > To save some time looking at the datasheet, the relevent bits in the > LINKS register are interpreted as follows. For the 2nd and 3rd values > I'll only give the deltas against the previous one. > > 744bef80: > link is up > 10G align status good > 10G lane sync status good all lanes > signal detected on all four lanes of 10G parallel > link status is up > > 34480f00: > link not up > 10G align status failed > 10g parallel lane sync status is failed > link status is down > > 34480100: > signal detected only on lane 0 of 10G parallel (lanes 1/2/3 no signal > detected) > > > So basically we start out with no signal, then after 100ms we transition > to the proper register values for a normal "up" link, then 45ms later we > lose the alignment status (but still have good lane sync status), and > finally 100ms later we lose signal detect on 3 of the 4 lanes. Does the link eventually come up? We may need to get an eeprom dump from the 82599 part you're working on as well. ethtool -e ethX should suffice. -- Jesse Brandeburg This email sent via Evolution, powered by Linux -- ___ 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
[E1000-devel] carrier detection issues at 10GB on XAUI with ixgbe driver on 2.6.27 x86 board
I'm seeing some strange behaviour with an 82599 using XAUI at 10GB. Intermittently we get a scenario where it seems to get stuck in the following loop: link detected as up 40-45ms delay link detected as down 2 sec delay The following is a detailed timeline for one specific event. Timestamps are in microseconds: 762926422: link tests as down, LINKS register 0x34480100 (100ms gap) 763026224: audit detects link up, LINKS register 0x744bef80 763026254: receive link state change interrupt via pci message, triggers watchdog to run (but it's already running) 763026260: link up message printed to log stream 763026383: link tests as up, LINKS register 0x744bef80 (45ms gap) 763071115: receive link state change interrupt via pci message 763071134: link tests as down, LINKS register 0x34480f00 763170935: link tests as down, LINKS register 0x34480100 Basically, as far as I can tell the LINKS register values match what we would expect to see if the far end was going up and down. However, the logs we have from the switch card (which admittedly don't give register-level information) don't show it bouncing the link up and down this fast. Any ideas what might be happening here? To save some time looking at the datasheet, the relevent bits in the LINKS register are interpreted as follows. For the 2nd and 3rd values I'll only give the deltas against the previous one. 744bef80: link is up 10G align status good 10G lane sync status good all lanes signal detected on all four lanes of 10G parallel link status is up 34480f00: link not up 10G align status failed 10g parallel lane sync status is failed link status is down 34480100: signal detected only on lane 0 of 10G parallel (lanes 1/2/3 no signal detected) So basically we start out with no signal, then after 100ms we transition to the proper register values for a normal "up" link, then 45ms later we lose the alignment status (but still have good lane sync status), and finally 100ms later we lose signal detect on 3 of the 4 lanes. Chris Friesen -- ___ 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
[E1000-devel] Performance issues with 82597EX 10GbE ethernet NIC
Dear sirs, In our research lab, we are experiencing performance issues with 2x 82597EX NICs (P/N PXLA8591CX4) connected back-to-back hosted on 2x IQ81342SC[1] evaluation boards. Our driver version is 1.0.135-k2-NAPI (vanilla linux-2.6.31 kernel). We are able to achieve ~280MiB/sec using jumbo frames, the following netperf test: netperf -H hostname -D -fM -t UDP_STREAM -- -m 8192 and the following module parameters: TxIntDelay=0 RxIntDelay=0 TxDescriptors=4096 RxDescriptors=512 FlowControl=0 XsumRX=0 IntDelayEnable=0 We have also tried increasing trasmit bursts via the MMRBC field in the PCI-X configuration registers (using setpci -d 8086:109e e6=2e). We finally built a microbenchmark in kernel space, using simple dev_queue_xmit() calls and found that the NIC's performance was bound to ~550MiB/sec while sending chunks of 524288 bytes using 9000-byte frames. During the test, the boards' overall CPU utilization did not exceed 1%. Is it possible that the PCI-X bus of the IQ81342SC boards cannot sustain more than ~550MiB/sec or are we missing something ? What do you suggest we do ? Thank you in advance for your help. Kind Regards, Anastassios Nanos [1] Board's description: http://download.intel.com/design/iio/docs/321899.pdf (board: IQ81342SC) Processor's manual: http://download.intel.com/design/iio/docs/31503702.pdf [2] lspci output: lspci -vv - -d 8086:109e 00:01.0 Ethernet controller: Intel Corporation 82597EX 10GbE Ethernet Controller (rev 02) Subsystem: Intel Corporation Device a00c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] [PATCH net-next] ixgbe: return error in set_rar when index out of range
Return -1 when set_rar index is out of range
Signed-off-by: Shirley Ma
---
drivers/net/ixgbe/ixgbe_common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c
b/drivers/net/ixgbe/ixgbe_common.c
index 1159d91..77b3cf4 100644
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1188,6 +1188,7 @@ s32 ixgbe_set_rar_generic(struct ixgbe_hw *hw, u32
index, u8 *addr, u32 vmdq,
IXGBE_WRITE_REG(hw, IXGBE_RAH(index), rar_high);
} else {
hw_dbg(hw, "RAR index %d is out of range.\n", index);
+ return -1;
}
return 0;
--
___
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
[E1000-devel] dual port PRO 1000 PT working at 10 Mbps
Dear all, First of all apologies if this list is not appropriate for such questions. We have a number of IBM System x3550 servers equiped with dual port PRO 1000 PT network cards. 13:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controll er (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Some of them don't get along with all our switches. In particular with our extreme networks summit x24T, cisco3750 and dell 6224. The link stays in 10 Mbps no matter what we try (cable changes, port changes, forcing port speed with ethtool or from switch settings, different rhel5 kernels, downloading driver and compiling it from intel website). When they are connected to the ports, the led flash about 3-4 times and the speed gets at 10 Mbps. However the same card will connect with 1 Gbps to a dell 5424 switch. Here is the ethtool output for one troubled system. eth0 is connected to the extreme networks switch, eth1 to the cisco one. Connecting eth0 to cisco with different cables does not help. However it worked for eth1 which had the same issue with the extreme switch, but linked fine at 1 Gbps with the cisco3750. Settings for eth0: 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: 10Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0001 (1) Link detected: yes 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: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0001 (1) Link detected: yes What can I try to resolve this problem? Are the cards just faulty (the problem is present to 4 identical nodes out of a total of 8). cheers, -- = Dimitris Zilaskos GridAUTH Operations Centre @ Aristotle University of Thessaloniki , Greece Tel: +302310998988 Fax: +302310994309 http://www.grid.auth.gr = -- ___ 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
