e1000 problems -- the nightmare has begun

This Dell Optiplex GX270 has a built-in NIC adapter, the Intel PRO/1000
Gigabit. Under Linux, I am using the e1000 driver and I am having all
sorts of problems.

The biggest problem is that my connections drop randomly. When using
PuTTY, I get

"Incorrect MAC received on packet" or
"Incoming packet was garbled on decryption"

When using ssh command line, I get

"Corrupted MAC on input"
or it just freezes

Another problem is that I am unable to connect via HTTP (port 80) to my
internal router's configuration screen. In particular, "telnet
192.168.1.1 80" says "Connection refused". It works on all my other
computers except this one; I even tried changing the IP address to one of
the other machines (just to see if it was firewall/filtering problem) and
that didn't work, either.

I compiled Linux kernel 2.4.27-10 (on Debian sid/unstable) with the
standard e1000 driver and it doesn't work. I also tried downloading and
installing the latest e1000 driver (11/11/2006 7.3.20) from Intel's web
site (this driver works with both 2.4 and 2.6 kerneles), but it doesn't
improve.

I also tried tweaking the speed, duplex, and autonegotiation of the e1000.
In particular, I tried setting it to 10 Mbps, full flow control, full
duplex, no interrupt throttle, and disabling of checksum offload:

options e1000 Duplex=2 FlowControl=3 Speed=10 InterruptThrottleRate=0 XsumRX=0

Doesn't help.

My routers are a Linksys BEFSR41 and a Linksys BEFW11S4 (wireless turned
off).

My other computers are a

generic Linux PC w/10 Mbps card (MTU = 1500)
another generic Linux PC w/10 Mbps card (MTU = 1500)
a Mac mini running @ 100 Mbps
Dell laptop w/Xircon 10/100 PC card running @ 10 Mbps

Here's the output from ifconfig:

% ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0D:56:27:1B:18
inet addr:192.168.2.5 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5406 errors:0 dropped:0 overruns:0 frame:0
TX packets:4179 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:615423 (600.9 KiB) TX bytes:429909 (419.8 KiB)
Base address:0xdf40 Memory:feae0000-feb00000

Here's the output from ethtool:

% sudo ethtool -S eth0
NIC statistics:
rx_packets: 5687
tx_packets: 4401
rx_bytes: 645299
tx_bytes: 452311
rx_broadcast: 132
tx_broadcast: 1
rx_multicast: 0
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 645299
rx_csum_offload_good: 5672
rx_csum_offload_errors: 0
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0

My kernel:

% uname -a
Linux darkstar 2.4.27-20070216 #1 Fri Feb 16 13:33:48 PST 2007 i686 GNU/Linux

jsp7rc002@sneakemail.com wrote:
> This Dell Optiplex GX270 has a built-in NIC adapter, the Intel PRO/1000
> Gigabit. Under Linux, I am using the e1000 driver and I am having all
> sorts of problems.
>
> The biggest problem is that my connections drop randomly. When using
> PuTTY, I get
>
> "Incorrect MAC received on packet" or
> "Incoming packet was garbled on decryption"
>
> When using ssh command line, I get
>
> "Corrupted MAC on input"
> or it just freezes
>
> Another problem is that I am unable to connect via HTTP (port 80) to my
> internal router's configuration screen. In particular, "telnet
> 192.168.1.1 80" says "Connection refused". It works on all my other
> computers except this one; I even tried changing the IP address to one of
> the other machines (just to see if it was firewall/filtering problem) and
> that didn't work, either.
>
> I compiled Linux kernel 2.4.27-10 (on Debian sid/unstable) with the
> standard e1000 driver and it doesn't work. I also tried downloading and
> installing the latest e1000 driver (11/11/2006 7.3.20) from Intel's web
> site (this driver works with both 2.4 and 2.6 kerneles), but it doesn't
> improve.
>
> I also tried tweaking the speed, duplex, and autonegotiation of the e1000.
> In particular, I tried setting it to 10 Mbps, full flow control, full
> duplex, no interrupt throttle, and disabling of checksum offload:
>
> options e1000 Duplex=2 FlowControl=3 Speed=10 InterruptThrottleRate=0 XsumRX=0
>
> Doesn't help.
>
> My routers are a Linksys BEFSR41 and a Linksys BEFW11S4 (wireless turned
> off).
>
> My other computers are a
>
> generic Linux PC w/10 Mbps card (MTU = 1500)
> another generic Linux PC w/10 Mbps card (MTU = 1500)
> a Mac mini running @ 100 Mbps
> Dell laptop w/Xircon 10/100 PC card running @ 10 Mbps
>
> Here's the output from ifconfig:
>
> % ifconfig -a
> eth0 Link encap:Ethernet HWaddr 00:0D:56:27:1B:18
> inet addr:192.168.2.5 Bcast:192.168.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:5406 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4179 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:615423 (600.9 KiB) TX bytes:429909 (419.8 KiB)
> Base address:0xdf40 Memory:feae0000-feb00000
>
> Here's the output from ethtool:
>
> % sudo ethtool -S eth0
> NIC statistics:
> rx_packets: 5687
> tx_packets: 4401
> rx_bytes: 645299
> tx_bytes: 452311
> rx_broadcast: 132
> tx_broadcast: 1
> rx_multicast: 0
> tx_multicast: 0
> rx_errors: 0
> tx_errors: 0
> tx_dropped: 0
> multicast: 0
> collisions: 0
> rx_length_errors: 0
> rx_over_errors: 0
> rx_crc_errors: 0
> rx_frame_errors: 0
> rx_no_buffer_count: 0
> rx_missed_errors: 0
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> tx_window_errors: 0
> tx_abort_late_coll: 0
> tx_deferred_ok: 0
> tx_single_coll_ok: 0
> tx_multi_coll_ok: 0
> tx_timeout_count: 0
> tx_restart_queue: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_align_errors: 0
> tx_tcp_seg_good: 0
> tx_tcp_seg_failed: 0
> rx_flow_control_xon: 0
> rx_flow_control_xoff: 0
> tx_flow_control_xon: 0
> tx_flow_control_xoff: 0
> rx_long_byte_count: 645299
> rx_csum_offload_good: 5672
> rx_csum_offload_errors: 0
> rx_header_split: 0
> alloc_rx_buff_failed: 0
> tx_smbus: 0
> rx_smbus: 0
> dropped_smbus: 0
>
> My kernel:
>
> % uname -a
> Linux darkstar 2.4.27-20070216 #1 Fri Feb 16 13:33:48 PST 2007 i686 GNU/Linux
>
The maintainers for the e1000 are given as:

P: Jeb Cramer
M: cramerj@intel.com
P: John Ronciak
M: john.ronciak@intel.com
P: Jesse Brandeburg
M: jesse.brandeburg@intel.com
P: Jeff Kirsher
M: jeffrey.t.kirsher@intel.com
P: Auke Kok
M: auke-jan.h.kok@intel.com

I would send your message to all of them as well as netdev@vger.kernel.org. Those addresses will get
your problem to the people that should know. I know that netdev has had a number of recent e1000
patches.

Larry

On 2007-02-17, jsp7rc002@sneakemail.com <jsp7rc002@sneakemail.com> wrote:
> This Dell Optiplex GX270 has a built-in NIC adapter, the Intel PRO/1000
> Gigabit. Under Linux, I am using the e1000 driver and I am having all
> sorts of problems.

The first thing you should do is crack open the case and have a look at the
capacitors on the motherboard. Are any bulging or corroded at the top? If
so, call up Dell and get a new motherboard. A *very* large number (but not
large enough for Dell to issue a recall) of GX270s were made with bad
capacitors, leading to all sorts of difficult to pin down problems.

In general, the e1000 is one of the best Linux gigabit drivers, and I run
several GX270s with this config and they work rather well (modulo the
motherboard issues above).

> The biggest problem is that my connections drop randomly. When using
> PuTTY, I get
>
> "Incorrect MAC received on packet" or
> "Incoming packet was garbled on decryption"
>
> When using ssh command line, I get
>
> "Corrupted MAC on input"
> or it just freezes

Given those issues, I'd also run memtest86 for at least 24hrs, and/or (if
you can) swap out the RAM. This sure sounds like data is getting corrupted
somewhere -- could be bad mobo, CPU, or RAM.

> I also tried tweaking the speed, duplex, and autonegotiation of the e1000.
> In particular, I tried setting it to 10 Mbps, full flow control, full
> duplex, no interrupt throttle, and disabling of checksum offload:
>
> options e1000 Duplex=2 FlowControl=3 Speed=10 InterruptThrottleRate=0 XsumRX=0

The gigabit standard mandates auto-negotiation. Forcing the adapter into a
mode is generally a Bad Thing.

--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

On Sun, 18 Feb 2007, Joshua Baker-LePain wrote:

> The gigabit standard mandates auto-negotiation. Forcing the adapter into a
> mode is generally a Bad Thing.

I wish I had a dollar for every gigabit adapter that I've had that
wouldn't auto-negotiate properly. Using Broadcom NIC's in HP DLxxx systems
talking to a Cisco 6xxx-series switch, using RHEL4 w/bonding, we had to
hard-wire the ports on over 30 systems to get them to work reliably.

Steve
----------------------------------------------------------------------------
Steve Thompson E-mail: smt AT vgersoft DOT com
Voyager Software LLC Web: http://www DOT vgersoft DOT com
39 Smugglers Path VSW Support: support AT vgersoft DOT com
Ithaca, NY 14850
"186,300 miles per second: it's not just a good idea, it's the law"
----------------------------------------------------------------------------

Steve Thompson <smt@vgersoft.com> wrote:
> I wish I had a dollar for every gigabit adapter that I've had that
> wouldn't auto-negotiate properly. Using Broadcom NIC's in HP DLxxx
> systems talking to a Cisco 6xxx-series switch, using RHEL4
> w/bonding, we had to hard-wire the ports on over 30 systems to get
> them to work reliably.

Did you ever experience that with a different model/brand of switch?

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

jsp7rc002@sneakemail.com wrote:
> This Dell Optiplex GX270 has a built-in NIC adapter, the Intel PRO/1000
> Gigabit. Under Linux, I am using the e1000 driver and I am having all
> sorts of problems.

> The biggest problem is that my connections drop randomly. When using
> PuTTY, I get

> "Incorrect MAC received on packet" or
> "Incoming packet was garbled on decryption"

> When using ssh command line, I get

> "Corrupted MAC on input"
> or it just freezes

Try disabling ChecKsum Offload if it is supported and enabled on the
kernels you are running. It would be an ethtool thing.

rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Tue, 20 Feb 2007, Rick Jones wrote:

> Steve Thompson <smt@vgersoft.com> wrote:
>> I wish I had a dollar for every gigabit adapter that I've had that
>> wouldn't auto-negotiate properly. Using Broadcom NIC's in HP DLxxx
>> systems talking to a Cisco 6xxx-series switch, using RHEL4
>> w/bonding, we had to hard-wire the ports on over 30 systems to get
>> them to work reliably.
>
> Did you ever experience that with a different model/brand of switch?

No, I did not get to test different brands in volume; all switches were
Cisco 6xxx series, and all NIC's were Broadcom.

Steve
----------------------------------------------------------------------------
Steve Thompson E-mail: smt AT vgersoft DOT com
Voyager Software LLC Web: http://www DOT vgersoft DOT com
39 Smugglers Path VSW Support: support AT vgersoft DOT com
Ithaca, NY 14850
"186,300 miles per second: it's not just a good idea, it's the law"
----------------------------------------------------------------------------

I managed to get it to work. I had to move to the 2.6.x kernel. (I can
only conclude that 2.4.x is now a mess since it doesn't work on my old
computer, either.)

Surprisingly, I still have problems when going through my Linksys router
to the WAN, but apparently this is a common problem which I can live with
-- I just want the LAN to work.