Forums

Resolved
0 votes
I am getting these errors occasionally from a ClearOS 6.7 system using an
intel e1000 NIC. They are not catastrophic as the NIC is reset and resumes
working...

...
Jan 22 05:42:13 alice kernel: next_to_watch.status <0>
Jan 22 05:42:15 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
Jan 22 05:42:15 alice kernel: Tx Queue <0>
Jan 22 05:42:15 alice kernel: TDH <c5>
Jan 22 05:42:15 alice kernel: TDT <d3>
Jan 22 05:42:15 alice kernel: next_to_use <d3>
Jan 22 05:42:15 alice kernel: next_to_clean <c3>
Jan 22 05:42:15 alice kernel: buffer_info[next_to_clean]
Jan 22 05:42:15 alice kernel: time_stamp <1c23e7e5>
Jan 22 05:42:15 alice kernel: next_to_watch <c5>
Jan 22 05:42:15 alice kernel: jiffies <1c23fd73>
Jan 22 05:42:15 alice kernel: next_to_watch.status <0>
Jan 22 05:42:17 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
Jan 22 05:42:17 alice kernel: Tx Queue <0>
Jan 22 05:42:17 alice kernel: TDH <c5>
Jan 22 05:42:17 alice kernel: TDT <d3>
Jan 22 05:42:17 alice kernel: next_to_use <d3>
Jan 22 05:42:17 alice kernel: next_to_clean <c3>
Jan 22 05:42:17 alice kernel: buffer_info[next_to_clean]
Jan 22 05:42:17 alice kernel: time_stamp <1c23e7e5>
Jan 22 05:42:17 alice kernel: next_to_watch <c5>
Jan 22 05:42:17 alice kernel: jiffies <1c240544>
Jan 22 05:42:17 alice kernel: next_to_watch.status <0>
Jan 22 05:42:18 alice kernel: e1000 0000:01:00.0: eth1: Reset adapter
Jan 22 05:42:22 alice kernel: e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
...

Also occasionally it stops dead and doesn't pass any packets - catastrophic.
a "service network restart" will fix this - so created a band aid using this
script while seeking a fix. Sends an email and logs time. Checks every
approx 5 minutes.

#!/bin/bash

# Restart network if the eth1 not communicating
# Version 1.0 A G Ellis

eth1_log_file="/var/log/eth1_log"

while :
do
ping_data=`ping -c 3 192.168.2.54` # ping to DIR-300 returns 0 if ok
rc=$?
if [[ $rc -gt 0 ]];then
/sbin/service network restart
echo "Warning - eth1 has failed on `/bin/hostname`..." \
| /bin/mail -s "Warning - eth1 has failed on `hostname`..." \
admin@sraellis.no-ip.com
/bin/date >> $eth1_log_file
fi
/bin/sleep 295

done


The NIC and driver in question...

01:00.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
Memory at fbee0000 (32-bit, non-prefetchable) [size=128K]
Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
I/O ports at dc00 [size=64]
Expansion ROM at 7f700000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Kernel driver in use: e1000
Kernel modules: e1000

filename: /lib/modules/2.6.32-573.1.1.v6.i686/kernel/drivers/net/e1000/e1000.ko
version: 7.3.21-k8-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>

That's a very old driver circa 2006/2007 :-( - how to update?
The Intel e1000 drivers are now on http://sourceforge.net. The latest is
8.0.35 - and are no longer maintained, so that is the final version.
Unfortunately this source will not compile on a ClearOS 6.7 system.
Elrepo has a kmod e1000 driver rpm at the 8.0.35 level, but naturally will
not install. So what to do?
Fortunately elrepo also has the source "e1000-kmod-8.0.35-1.el6.elrepo.src.rpm"
- at least the driver should compile on a Redhat Enterprise based system. Just
ignore the kmod bit... so downloaded and installed the source rpm. Naturally an
rpmbuilt will not work, but...
went into /root/rpmbuild/BUILD/e1000-8.0.35/src and there was the traditional
e1000 source complete with a Makefile. A 'make' and a 'make install' worked
wonderfully replacing the old e1000.ko with a brand new one...

filename: /lib/modules/2.6.32-573.1.1.v6.i686/kernel/drivers/net/e1000/e1000.ko
version: 8.0.35-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>

Naturally you must have the development software installed to do this (see elsewhere
on these forums)

Maybe this technique can be used to update other drivers and of use to somebody?
Now waiting to see if my problem is resolved...

EDIT: Sorry - I forgot a vital step :-(
after installing the source rpm you must "cd /root/rpmbuild/SPECS" and try to rpmbuild
"rpmbuild -ba e1000-kmod.spec". It will fail, but will unpack the source for you in
"/root/rpmbuild/BUILD/e1000-8.0.35/src"
Friday, January 22 2016, 02:35 AM
Share this post:
Responses (62)
  • Accepted Answer

    Friday, January 22 2016, 08:28 AM - #Permalink
    Resolved
    0 votes
    I'll post back from home later when I'm there and when I get my internet connection back. :(

    Searching the forum, it looks like this is how I build kmod packages. The "kversion" parameter is important otherwise it will not build. I am doing it from a mini-script as I build a number of different packages so the command can easily be simplified into a one liner for a one off build.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, January 23 2016, 01:15 PM - #Permalink
    Resolved
    0 votes
    Thanks Nick - my main aim is to find what is required to fix this NIC, if possible by a newer driver, and to see if anybody has encountered this before... no need to re-invent the wheel. In searching 'the Net' it seems like a lot of hangs with E1000 happened during buffer transfers i.e. memory to memory copying. I was interested to see this difference between the two versions with "parm: ignore_64bit_dma:Ignore 64-bit DMA (DAC) capability (int)" being added to the newer...

    I realize this could be hardware - the PCI NIC adapter card or motherboard. I have another identical NIC, but with a normal bracket instead of half -height. That is easy and trivial to swap, but the location of the other machine in which it is installed is difficult to get at - so want to leave that option until the very last - hoping it doesn't need to happen:-)

    I will later fix rpmbuild, thanks for the link - on CentOS the additional stuff that seems necessary for ClearOS, is not required. At the time it was so much easier to issue "make" and "make install" - rather than researching or figuring out how to get rpmbuild to work, create the rpm, then install the rpm back on the self same machine; rpmbuild is great for creating an rpm on one machine, then installing that rpm on others...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 25 2016, 09:53 AM - #Permalink
    Resolved
    0 votes
    Hi Tony

    Exactly the same issues with me that have only started recently. Also running 6.7.

    I initially thought is was new hardware, but I am now back on my old server and also getting interface hangs followed sometimes by complete system hang i.e. no traffic over the interface.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 25 2016, 12:23 PM - #Permalink
    Resolved
    0 votes
    @Duncan,
    If you are running the 64bit ClearOS I can compile the kmod-e1000 rpm for you this evening. I do not have a 32bit set up and don't know how to cross-compile so I can't produce the 32bit rpm.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 25 2016, 01:02 PM - #Permalink
    Resolved
    0 votes
    Hi Nick

    Yes 64bit

    2.6.32-504.23.4.v6.x86_64


    Much appreciated
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 25 2016, 02:21 PM - #Permalink
    Resolved
    0 votes
    Thanks Nick - your script works well... looks like we overlapped...
    Since my trouble-some machine was 32-bit... kmod-e1000-8.0.35-1.v6.i686.rpm

    available from :-

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.i686.rpm

    then, since I also have a 64-bit m/c, repeated everything there :-

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.x86_64.rpm
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 11 2016, 11:21 PM - #Permalink
    Resolved
    0 votes
    Update :-
    No more occasional hangs so far... This is the last before the new driver was installed Jan 26th 2016

    /var/log/messages-20160124:Jan 22 05:42:11 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
    /var/log/messages-20160124:Jan 22 05:42:13 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
    /var/log/messages-20160124:Jan 22 05:42:15 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
    /var/log/messages-20160124:Jan 22 05:42:17 alice kernel: e1000 0000:01:00.0: eth1: Detected Tx Unit Hang
    /var/log/messages-20160124:Jan 22 05:42:18 alice kernel: e1000 0000:01:00.0: eth1: Reset adapter

    Also just discovered this tip :-
    https://fasterdata.es.net/host-tuning/nic-tuning/
    Both the E1000 NICs here are the newer version, so now running with 4096 Rx and Tx descriptors. No idea if this will help the hang problem, but should help performance - will continue to monitor.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 08 2016, 08:53 AM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    Thanks Nick - your script works well... looks like we overlapped...
    Since my trouble-some machine was 32-bit... kmod-e1000-8.0.35-1.v6.i686.rpm

    available from :-

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.i686.rpm

    then, since I also have a 64-bit m/c, repeated everything there :-

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.x86_64.rpm


    Hello
    I'm having the same errors in my log on my ClearOS 7.2 server.

    Can i use this rpm without any problems ?

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.x86_64.rpm
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 08 2016, 09:47 AM - #Permalink
    Resolved
    0 votes
    Patrick de Brabander wrote:
    Hello
    I'm having the same errors in my log on my ClearOS 7.2 server.

    Can i use this rpm without any problems ?

    http://danda.poweredbyclear.com/kmod-clearos/kmod-e1000-8.0.35-1.v6.x86_64.rpm
    No as it has been compiled against a different base kernel. ElRepo do not appear to maintain an el7 version of the e1000 driver, presumably because it is now fully incorporated in the kernel. I'd need to check which version is there, or can you do a "modinfo e1000" to check the version? The latest version from Intel is 8.0.35.

    I can try compiling the el6 source against the ClearOS7 kernel but I've absolutely no idea if it will work. Are you running the latest kernel?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 08 2016, 10:01 AM - #Permalink
    Resolved
    0 votes
    Hi Nick,
    This is the output of modinfo e1000:

     modinfo e1000
    filename: /lib/modules/3.10.0-327.10.1.v7.x86_64/kernel/drivers/net/ethern et/intel/e1000/e1000.ko
    version: 7.3.21-k8-NAPI
    license: GPL
    description: Intel(R) PRO/1000 Network Driver
    author: Intel Corporation, <linux.nics@intel.com>
    rhelversion: 7.2
    srcversion: 4354B761874070384453524
    alias: pci:v00008086d00002E6Esv*sd*bc*sc*i*
    alias: pci:v00008086d000010B5sv*sd*bc*sc*i*
    alias: pci:v00008086d00001099sv*sd*bc*sc*i*
    alias: pci:v00008086d0000108Asv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Csv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Bsv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Asv*sd*bc*sc*i*
    alias: pci:v00008086d00001079sv*sd*bc*sc*i*
    alias: pci:v00008086d00001078sv*sd*bc*sc*i*
    alias: pci:v00008086d00001077sv*sd*bc*sc*i*
    alias: pci:v00008086d00001076sv*sd*bc*sc*i*
    alias: pci:v00008086d00001075sv*sd*bc*sc*i*
    alias: pci:v00008086d00001028sv*sd*bc*sc*i*
    alias: pci:v00008086d00001027sv*sd*bc*sc*i*
    alias: pci:v00008086d00001026sv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Esv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Dsv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Asv*sd*bc*sc*i*
    alias: pci:v00008086d00001019sv*sd*bc*sc*i*
    alias: pci:v00008086d00001018sv*sd*bc*sc*i*
    alias: pci:v00008086d00001017sv*sd*bc*sc*i*
    alias: pci:v00008086d00001016sv*sd*bc*sc*i*
    alias: pci:v00008086d00001015sv*sd*bc*sc*i*
    alias: pci:v00008086d00001014sv*sd*bc*sc*i*
    alias: pci:v00008086d00001013sv*sd*bc*sc*i*
    alias: pci:v00008086d00001012sv*sd*bc*sc*i*
    alias: pci:v00008086d00001011sv*sd*bc*sc*i*
    alias: pci:v00008086d00001010sv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Fsv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Esv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Dsv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Csv*sd*bc*sc*i*
    alias: pci:v00008086d00001009sv*sd*bc*sc*i*
    alias: pci:v00008086d00001008sv*sd*bc*sc*i*
    alias: pci:v00008086d00001004sv*sd*bc*sc*i*
    alias: pci:v00008086d00001001sv*sd*bc*sc*i*
    alias: pci:v00008086d00001000sv*sd*bc*sc*i*
    depends:
    intree: Y
    vermagic: 3.10.0-327.10.1.v7.x86_64 SMP mod_unload modversions
    signer: CentOS Linux kernel signing key
    sig_key: CB:7F:79:27:7A:10:CF:B2:6D:D6:2E:3D:33:A0:DF:1F:26:DD:83:AD
    sig_hashalgo: sha256
    parm: TxDescriptors:Number of transmit descriptors (array of int)
    parm: RxDescriptors:Number of receive descriptors (array of int)
    parm: Speed:Speed setting (array of int)
    parm: Duplex:Duplex setting (array of int)
    parm: AutoNeg:Advertised auto-negotiation setting (array of int)
    parm: FlowControl:Flow Control setting (array of int)
    parm: XsumRX:Disable or enable Receive Checksum offload (array of int)
    parm: TxIntDelay:Transmit Interrupt Delay (array of int)
    parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
    parm: RxIntDelay:Receive Interrupt Delay (array of int)
    parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
    parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
    parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
    parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
    parm: debug:Debug level (0=none,...,16=all) (int)



    Kernel:
    uname -a
    Linux pdebrabander.nl 3.10.0-327.10.1.v7.x86_64 #1 SMP Sat Mar 5 19:10:52 MST 2016 x86_64 x86_64 x86_64 GNU/Linux


    When you compile a driver, is this only usable for this kernel version ? or also usable for future kernel upgrades ?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 08 2016, 10:37 AM - #Permalink
    Resolved
    0 votes
    If you compile a kmod/ElRepo driver then my understanding is that it should not need recompiling for any minor kernel version change, so a kmod driver compiled for 3.10.0-327.10.1.v7.x86_64 should work for any 3.10.0 kernel. ClearOS x uses a 2.6.32 kernel.

    If you use other sources, then generally they need recompiling for every minor kernel update.

    You are welcome to compile from Intel's source from their site but you will probably have to recompile it for every kernel update as I don't think they are kabi compatible. kabi compatibility is what ElRepo use to avoid recompilation on kernel change.

    I tried compiling the el6 ElRepo source against ClearOS7 and it failed.

    [edit]
    You could try requesting an el7 source on the ElRepo mailing list and see if someone will create it. I can then compile it.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 09 2016, 05:08 AM - #Permalink
    Resolved
    0 votes
    Unfortunately the README in the Intel source for e1000 has this :-

    In This Release
    ===============

    This file describes the e1000 Linux* Base Driver for Intel Ethernet Network
    Connection. This driver supports kernel versions 2.4.x and 2.6.x. This driver
    includes support for Itanium(R)2-based systems.

    It doesn't compile on a 3.x system - so that is the major problem.
    Had it compiled, I probably could have made a kmod driver from it...
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 09 2016, 02:33 PM - #Permalink
    Resolved
    0 votes
    That's a pity. Presumably that means going all the way up to the kernel developers to update the driver! Or to Intel?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 09 2016, 03:25 PM - #Permalink
    Resolved
    0 votes
    Check it out, but as I understand it the last version from Intel was 8.0.35 and they ceased releasing upgrades as the e1000 product had been discontinued and is now legacy.
    the changelog for 8.0.35 contradicts the README

    ChangeLog for e1000-8.0.35
    =====================
    * Fix unresolved symbol errors under 2.4.0 kernels
    * Fix panic issue because of of NULL vlgrp in e1000_vlan_rx_add_vid()
    * Added ethtool set_phys_id
    * Fix driver build issue under 3.x.x kernels
    * Fix kernel panic due to buffer_info->skb == NULL in e1000_clean_tx_irq()
    * Forbid writing to module parameter ignore_64bit_dma via sysfs
    The module parameter ignore_64bit_dma is a module load time parameter only.

    When I tried compiling it on ClearOS 7.2 it immediately complained of missing source files. Initially I was able to find them - they were just in a different directories to where it was looking, and fixed them one by one using symlinks. Then it got to the point it wanted a file that didn't exist on 7.2. I found it existed in the ClearOS 6.x. At that point I gave up. So far I haven't found an alternative 8.0.35 e1000 source, let alone one that compiles with kernel 3.x .x on 7.x

    Edit: I have subsequently found out that the "missing" file actually existed in 3.1.x kernels, but was removed from subsequent ones for some reason or other. Not going to go looking for it...
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 10 2016, 04:48 PM - #Permalink
    Resolved
    0 votes
    I think this is the end of the e1000 saga for kernel 3.1

    See https://elrepo.org/bugs/view.php?id=631&nbn=3

    Seems like the e1000 driver with the older version number in the 3.x kernels is receiving new patches after the newer driver was released by Intel.
    So the older driver is now the newer driver :-) if you can make sense out of that...

    https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/intel/e1000 confirms updates taking place...
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 10 2016, 05:09 PM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:

    I think this is the end of the e1000 saga for kernel 3.1

    See https://elrepo.org/bugs/view.php?id=631&nbn=3

    Seems like the e1000 driver with the older version number in the 3.x kernels is receiving new patches after the newer driver was released by Intel.
    So the older driver is now the newer driver :-) if you can make sense out of that...

    https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/intel/e1000 confirms updates taking place...


    I'm lost.....
    when you check this site : Title
    The most recent change in 20.01.2016... version 3.3.3

    But..... is it possible to compile a driver for ClearOS 7.x with these source code?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 10 2016, 05:30 PM - #Permalink
    Resolved
    0 votes
    The e1000e driver is for PCI-E cards and is not the same as the e1000 which is for PCI cards, but it is interesting that if you look at the e1000 8.0.35 driver, it says in the release notes:
    * Fix driver build issue under 3.x.x kernels
    . I may try and build it.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 10 2016, 05:59 PM - #Permalink
    Resolved
    0 votes
    No, it won't build :(
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 14 2016, 07:29 PM - #Permalink
    Resolved
    0 votes
    Don't hold your breath, but I got this from the Elrepo mailing list in the last few minutes:
    On May 10, 2016 11:11, "Nick Howitt" <xxxx@xxxxxxx.co.uk> wrote:
    >
    > Hi,
    >
    > We have someone in using ClearOS7 (CentOS7 derivative) who is having problems with the e1000 driver built into the kernel (7.3.21-k8-NAPI on 3.10.0-327.10.1.v7.x86_64). The latest Intel driver is 8.0.35. In its change log on sourceforge it says "* Fix driver build issue under 3.x.x kernels", however I cannot get it to build, and in any case it will need recompiling for every kernel update. I suspect the driver is now unmaintained as it has not been updated since 11/10/2011.
    >
    > Is there any chance that one of you fine geniuses can create an el7 compatible kmod version?
    >
    > Many thanks,
    >
    > Nick

    Just wanted to note that we are working on it but no promise, no ETA.

    Akemi
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 20 2016, 02:44 AM - #Permalink
    Resolved
    0 votes
    I'm having problems with clearos 7, the intel nix hangs and i have to reset the computer. this just started ~30 days ago...

    "e1000e 0000:00:19.0 eno1: Detected hardware Unit Hang:"

    # modinfo e1000
    filename: /lib/modules/3.10.0-327.10.1.v7.x86_64/kernel/drivers/net/ethernet/intel/e1000/e1000.ko
    version: 7.3.21-k8-NAPI
    license: GPL
    description: Intel(R) PRO/1000 Network Driver
    author: Intel Corporation, <linux.nics@intel.com>
    rhelversion: 7.2
    srcversion: 4354B761874070384453524
    alias: pci:v00008086d00002E6Esv*sd*bc*sc*i*
    alias: pci:v00008086d000010B5sv*sd*bc*sc*i*
    alias: pci:v00008086d00001099sv*sd*bc*sc*i*
    alias: pci:v00008086d0000108Asv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Csv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Bsv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Asv*sd*bc*sc*i*
    alias: pci:v00008086d00001079sv*sd*bc*sc*i*
    alias: pci:v00008086d00001078sv*sd*bc*sc*i*
    alias: pci:v00008086d00001077sv*sd*bc*sc*i*
    alias: pci:v00008086d00001076sv*sd*bc*sc*i*
    alias: pci:v00008086d00001075sv*sd*bc*sc*i*
    alias: pci:v00008086d00001028sv*sd*bc*sc*i*
    alias: pci:v00008086d00001027sv*sd*bc*sc*i*
    alias: pci:v00008086d00001026sv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Esv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Dsv*sd*bc*sc*i*
    alias: pci:v00008086d0000101Asv*sd*bc*sc*i*
    alias: pci:v00008086d00001019sv*sd*bc*sc*i*
    alias: pci:v00008086d00001018sv*sd*bc*sc*i*
    alias: pci:v00008086d00001017sv*sd*bc*sc*i*
    alias: pci:v00008086d00001016sv*sd*bc*sc*i*
    alias: pci:v00008086d00001015sv*sd*bc*sc*i*
    alias: pci:v00008086d00001014sv*sd*bc*sc*i*
    alias: pci:v00008086d00001013sv*sd*bc*sc*i*
    alias: pci:v00008086d00001012sv*sd*bc*sc*i*
    alias: pci:v00008086d00001011sv*sd*bc*sc*i*
    alias: pci:v00008086d00001010sv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Fsv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Esv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Dsv*sd*bc*sc*i*
    alias: pci:v00008086d0000100Csv*sd*bc*sc*i*
    alias: pci:v00008086d00001009sv*sd*bc*sc*i*
    alias: pci:v00008086d00001008sv*sd*bc*sc*i*
    alias: pci:v00008086d00001004sv*sd*bc*sc*i*
    alias: pci:v00008086d00001001sv*sd*bc*sc*i*
    alias: pci:v00008086d00001000sv*sd*bc*sc*i*
    depends:
    intree: Y
    vermagic: 3.10.0-327.10.1.v7.x86_64 SMP mod_unload modversions
    signer: CentOS Linux kernel signing key
    sig_key: CB:7F:79:27:7A:10:CF:B2:6D:D6:2E:3D:33:A0:DF:1F:26:DD:83:AD
    sig_hashalgo: sha256
    parm: TxDescriptors:Number of transmit descriptors (array of int)
    parm: RxDescriptors:Number of receive descriptors (array of int)
    parm: Speed:Speed setting (array of int)
    parm: Duplex:Duplex setting (array of int)
    parm: AutoNeg:Advertised auto-negotiation setting (array of int)
    parm: FlowControl:Flow Control setting (array of int)
    parm: XsumRX:Disable or enable Receive Checksum offload (array of int)
    parm: TxIntDelay:Transmit Interrupt Delay (array of int)
    parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
    parm: RxIntDelay:Receive Interrupt Delay (array of int)
    parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
    parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
    parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
    parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
    parm: debug:Debug level (0=none,...,16=all) (int)
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 20 2016, 04:08 AM - #Permalink
    Resolved
    0 votes
    Rather than a reboot, does it recover with this hammer?

    # systemctl restart network.service

    If so, then create a script similar to the one at the bottom of this append tailored to your system and run it in the background e.g.

    # /path_to/check_e1000.sh &

    This will at least provide a temporary work-around...
    Note the script assumes you have mail working and the mailx rpm installed. It also creates a tiny log entry. Remove the section to send an email if your system doesn't support it.

    see this thead for more on the E1000 on Centos 7.x and Nick's attempt for an e1000 kmod rpm for ClearOS 7.x
    https://www.clearos.com/clearfoundation/social/community/repeating-logentries-kernel-net-unregistered-protocol-family-36

    #!/bin/bash

    # check_e1000.sh
    # Restart network if the eth1 not communicating
    # Version 1.0 A G Ellis 16 Jan 2016
    # Version 1.1 for ClearOS 7.x - 20 May 2016

    eth1_log_file="/var/log/eth1_log"

    while :
    do
    ping_data=`ping -c 3 192.168.2.34` # ping may.sraellis.com returns 0 if ok
    rc=$?
    if [[ $rc -gt 0 ]];then
    echo "eth1 has failed..."
    systemctl restart network.service
    echo "Warning - ping may on eth1 has failed on `hostname`..." \
    | mail -s "Warning - ping may on eth1 has failed on `hostname`..."\
    admin@sraellis.no-ip.com
    date >> $eth1_log_file
    fi
    /sleep 295

    done
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 20 2016, 07:08 AM - #Permalink
    Resolved
    0 votes
    I'm not sure this is going the right way. Eric has done a modinfo on e1000, but the error message he reported was for e1000e.

    Eric,
    If the error is really on e1000e, you can try installing my kmod-e1000e package from here. You can confirm which you are using with a:
    lspci -k | grep Eth -A 3


    FWIW, the e1000 driver is for PCI cards and the e1000e for PCI-E cards.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 20 2016, 07:36 AM - #Permalink
    Resolved
    0 votes
    Your right Nick - Didn't see that... would be better if Eric really has an NIC requiring the e1000e driver to put that in a separate thread and avoid the (my) confusion which has compounded the problem :-(

    Actually, for every rule it seems that there is an exception....

    One very early PCI-express NIC from Intel that used an old PCI NIC chipset (82546) and a PCI -> PCI-express bridge requires the e1000 driver...
    It's the Intel(R) PRO/1000 P Dual Port Server Adapter for a PCI-express slot.

    https://downloadmirror.intel.com/20927/eng/e1000.htm
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 21 2016, 04:50 AM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    I'm not sure this is going the right way. Eric has done a modinfo on e1000, but the error message he reported was for e1000e.

    Eric,
    If the error is really on e1000e, you can try installing my kmod-e1000e package from here. You can confirm which you are using with a:
    lspci -k | grep Eth -A 3


    FWIW, the e1000 driver is for PCI cards and the e1000e for PCI-E cards.


    your driver is ver 3.3.3-1 where the one in the kernel is ver 3.2.5-k. I wonder what was changed in the driver?

    # lspci -k | grep Eth -A 2
    00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
    Subsystem: Gigabyte Technology Co., Ltd Device e000
    Kernel driver in use: e1000e
    --
    07:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10)
    Subsystem: Gigabyte Technology Co., Ltd Device e000
    Kernel driver in use: alx


    here is the correct modinfo:

    # modinfo e1000e
    filename: /lib/modules/3.10.0-327.10.1.v7.x86_64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
    version: 3.2.5-k
    license: GPL
    description: Intel(R) PRO/1000 Network Driver
    author: Intel Corporation, <linux.nics@intel.com>
    rhelversion: 7.2
    srcversion: 7097C005F85B5C9D374D3FB
    alias: pci:v00008086d000015B8sv*sd*bc*sc*i*
    alias: pci:v00008086d000015B7sv*sd*bc*sc*i*
    alias: pci:v00008086d00001570sv*sd*bc*sc*i*
    alias: pci:v00008086d0000156Fsv*sd*bc*sc*i*
    alias: pci:v00008086d000015A3sv*sd*bc*sc*i*
    alias: pci:v00008086d000015A2sv*sd*bc*sc*i*
    alias: pci:v00008086d000015A1sv*sd*bc*sc*i*
    alias: pci:v00008086d000015A0sv*sd*bc*sc*i*
    alias: pci:v00008086d00001559sv*sd*bc*sc*i*
    alias: pci:v00008086d0000155Asv*sd*bc*sc*i*
    alias: pci:v00008086d0000153Bsv*sd*bc*sc*i*
    alias: pci:v00008086d0000153Asv*sd*bc*sc*i*
    alias: pci:v00008086d00001503sv*sd*bc*sc*i*
    alias: pci:v00008086d00001502sv*sd*bc*sc*i*
    alias: pci:v00008086d000010F0sv*sd*bc*sc*i*
    alias: pci:v00008086d000010EFsv*sd*bc*sc*i*
    alias: pci:v00008086d000010EBsv*sd*bc*sc*i*
    alias: pci:v00008086d000010EAsv*sd*bc*sc*i*
    alias: pci:v00008086d00001525sv*sd*bc*sc*i*
    alias: pci:v00008086d000010DFsv*sd*bc*sc*i*
    alias: pci:v00008086d000010DEsv*sd*bc*sc*i*
    alias: pci:v00008086d000010CEsv*sd*bc*sc*i*
    alias: pci:v00008086d000010CDsv*sd*bc*sc*i*
    alias: pci:v00008086d000010CCsv*sd*bc*sc*i*
    alias: pci:v00008086d000010CBsv*sd*bc*sc*i*
    alias: pci:v00008086d000010F5sv*sd*bc*sc*i*
    alias: pci:v00008086d000010BFsv*sd*bc*sc*i*
    alias: pci:v00008086d000010E5sv*sd*bc*sc*i*
    alias: pci:v00008086d0000294Csv*sd*bc*sc*i*
    alias: pci:v00008086d000010BDsv*sd*bc*sc*i*
    alias: pci:v00008086d000010C3sv*sd*bc*sc*i*
    alias: pci:v00008086d000010C2sv*sd*bc*sc*i*
    alias: pci:v00008086d000010C0sv*sd*bc*sc*i*
    alias: pci:v00008086d00001501sv*sd*bc*sc*i*
    alias: pci:v00008086d00001049sv*sd*bc*sc*i*
    alias: pci:v00008086d0000104Dsv*sd*bc*sc*i*
    alias: pci:v00008086d0000104Bsv*sd*bc*sc*i*
    alias: pci:v00008086d0000104Asv*sd*bc*sc*i*
    alias: pci:v00008086d000010C4sv*sd*bc*sc*i*
    alias: pci:v00008086d000010C5sv*sd*bc*sc*i*
    alias: pci:v00008086d0000104Csv*sd*bc*sc*i*
    alias: pci:v00008086d000010BBsv*sd*bc*sc*i*
    alias: pci:v00008086d00001098sv*sd*bc*sc*i*
    alias: pci:v00008086d000010BAsv*sd*bc*sc*i*
    alias: pci:v00008086d00001096sv*sd*bc*sc*i*
    alias: pci:v00008086d0000150Csv*sd*bc*sc*i*
    alias: pci:v00008086d000010F6sv*sd*bc*sc*i*
    alias: pci:v00008086d000010D3sv*sd*bc*sc*i*
    alias: pci:v00008086d0000109Asv*sd*bc*sc*i*
    alias: pci:v00008086d0000108Csv*sd*bc*sc*i*
    alias: pci:v00008086d0000108Bsv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Fsv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Esv*sd*bc*sc*i*
    alias: pci:v00008086d0000107Dsv*sd*bc*sc*i*
    alias: pci:v00008086d000010B9sv*sd*bc*sc*i*
    alias: pci:v00008086d000010D5sv*sd*bc*sc*i*
    alias: pci:v00008086d000010DAsv*sd*bc*sc*i*
    alias: pci:v00008086d000010D9sv*sd*bc*sc*i*
    alias: pci:v00008086d00001060sv*sd*bc*sc*i*
    alias: pci:v00008086d000010A5sv*sd*bc*sc*i*
    alias: pci:v00008086d000010BCsv*sd*bc*sc*i*
    alias: pci:v00008086d000010A4sv*sd*bc*sc*i*
    alias: pci:v00008086d0000105Fsv*sd*bc*sc*i*
    alias: pci:v00008086d0000105Esv*sd*bc*sc*i*
    depends: ptp
    intree: Y
    vermagic: 3.10.0-327.10.1.v7.x86_64 SMP mod_unload modversions
    signer: CentOS Linux kernel signing key
    sig_key: CB:7F:79:27:7A:10:CF:B2:6D:D6:2E:3D:33:A0:DF:1F:26:DD:83:AD
    sig_hashalgo: sha256
    parm: debug:Debug level (0=none,...,16=all) (int)
    parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
    parm: TxIntDelay:Transmit Interrupt Delay (array of int)
    parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
    parm: RxIntDelay:Receive Interrupt Delay (array of int)
    parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
    parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
    parm: IntMode:Interrupt Mode (array of int)
    parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
    parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
    parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
    parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, May 21 2016, 07:32 AM - #Permalink
    Resolved
    0 votes
    3.3.3 is very recent so I guess will take a while to get into the kernel natively. The info on Intel's page has an out of date change log so it does not help.

    Interestingly, the stock kernel version is later than the previous generally released version (3.1.0.2)!

    kmod (ElRepo) drivers should normally survive a kernel upgrade, and, if they don't, ClearOS justs fall back to using the stock kernel module. There was one kernel upgrade for the e1000e and igb NIC's in the ClearOS 6.x kernels which broke compatibility and the drivers needed recompiling, but that is the only time I've ever seen it happen.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 07:08 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    ...try installing my kmod-e1000e package from here.


    Install with rpm -ivh kmod-e1000e-3.3.3-1.clearos7.njh.x86_64.rpm?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 07:15 PM - #Permalink
    Resolved
    0 votes
    Yes, or to avoid future yum warnings do:
    yum localinstall --nogpgcheck kmod-e1000e-3.3.3-1.clearos7.njh.x86_64.rpm
    or else do a "yum clean all" after installing using rpm.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 07:37 PM - #Permalink
    Resolved
    0 votes
    I installed using yum as you suggested, confirmed it is running. will be interesting to see if this cures the nic hanging issue.

    # modinfo e1000e
    filename: /lib/modules/3.10.0-327.10.1.v7.x86_64/extra/e1000e/e1000e.ko
    version: 3.3.3-NAPI
    license: GPL
    description: Intel(R) PRO/1000 Network Driver
    author: Intel Corporation, <linux.nics@intel.com>
    rhelversion: 7.2
    srcversion: BC7D8BD3880A3E5F62C57D7
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 08:05 PM - #Permalink
    Resolved
    0 votes
    Unless you've either rebooted or done some command line manipulation, you'll still be running the old driver.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 08:23 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Unless you've either rebooted or done some command line manipulation, you'll still be running the old driver.

    I rebooted: # shutdown -r now

    doesn't modinfo show the current module in use?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 08:34 PM - #Permalink
    Resolved
    0 votes
    Maybe you try this

    modprobe e1000e
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 08:41 PM - #Permalink
    Resolved
    0 votes
    Your shutdown line is a reboot so you're fine.

    As far as I know, modinfo gives the result of the latest installed module and not the running module. It will give a result on any module whether it is loaded or not. To update a module without rebooting you need to at least unload the old module and then load in the new one and restart networking. You may also need a "depmod -a" if the installation routine does not do it for you. It is not a good idea to do this if the NIC is in use. A reboot is much easier.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, May 22 2016, 08:43 PM - #Permalink
    Resolved
    0 votes
    Patrick de Brabander wrote:

    Maybe you try this

    modprobe e1000e
    ..... Doesn't work if the module is already loaded
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 23 2016, 03:03 AM - #Permalink
    Resolved
    0 votes
    # dmesg | grep e1000e -A 3
    [ 0.693470] e1000e: module verification failed: signature and/or required key missing - tainting kernel
    [ 0.693890] e1000e: Intel(R) PRO/1000 Network Driver - 3.3.3-NAPI
    [ 0.693891] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
    [ 0.694032] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
    [ 0.694048] e1000e 0000:00:19.0: irq 27 for MSI/MSI-X
    [ 0.694060] libata version 3.00 loaded.
    [ 0.696126] [drm] Initialized drm 1.1.0 20060810
    [ 0.718512] alx 0000:07:00.0 eth0: Qualcomm Atheros AR816x/AR817x Ethernet [90:2b:34:da:f5:36]
    --
    [ 0.949855] e1000e 0000:00:19.0 eth0: registered PHC clock
    [ 0.949860] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 90:2b:34:da:f5:34
    [ 0.949862] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
    [ 0.949908] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
    [ 0.949954] ahci 0000:00:1f.2: version 3.0
    [ 0.950092] ahci 0000:00:1f.2: irq 28 for MSI/MSI-X
    [ 0.960670] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
    --
    [ 5.792953] e1000e 0000:00:19.0: irq 27 for MSI/MSI-X
    [ 5.893834] e1000e 0000:00:19.0: irq 27 for MSI/MSI-X
    [ 5.893916] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready
    [ 7.418216] e1000e: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
    [ 7.418221] e1000e 0000:00:19.0 eno1: 10/100 speed: disabling TSO
    [ 7.418252] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
    [ 13.157850] alx 0000:07:00.0: irq 36 for MSI/MSI-X
    [ 13.157906] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready


    poking around in /sys

    # ls /sys/class/net/eno1/device/driver/module/version
    anaconda-ks.cfg .cshrc
    .bash_history kmod-e1000e-3.3.3-1.clearos7.njh.x86_64.rpm
    .bash_logout .pki/
    .bash_profile .rnd
    .bashrc .tcshrc
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 01 2016, 07:48 PM - #Permalink
    Resolved
    0 votes
    Tony Ellis wrote:


    ...
    [/code]
    Also occasionally it stops dead and doesn't pass any packets - catastrophic.
    a "service network restart" will fix this - so created a band aid using this
    script while seeking a fix. Sends an email and logs time. Checks every
    approx 5 minutes.

    #!/bin/bash

    # Restart network if the eth1 not communicating
    # Version 1.0 A G Ellis

    eth1_log_file="/var/log/eth1_log"

    while :
    do
    ping_data=`ping -c 3 192.168.2.54` # ping to DIR-300 returns 0 if ok
    rc=$?
    if [[ $rc -gt 0 ]];then
    /sbin/service network restart
    echo "Warning - eth1 has failed on `/bin/hostname`..." \
    | /bin/mail -s "Warning - eth1 has failed on `hostname`..." \
    admin@sraellis.no-ip.com
    /bin/date >> $eth1_log_file
    fi
    /bin/sleep 295

    done




    Hi Tony,

    just had today a full list of errors with the network.
    So used the band-aid "service network restart" and it is runnnig again.

    Just a question about your script.
    Are you running this in a cronjob ?
    And what address are you ping-ing ? Is this the IP of ETH1 ?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 01 2016, 10:34 PM - #Permalink
    Resolved
    0 votes
    Hi Patrick

    No, it is not run by cron. It is a self contained loop that once started will run forever unless killed :-)
    Loops every 295 seconds. Started from an entry in /etc/rc.d/rc.local.

    In this case eth1 is on the 192.168.2.0/24 network - and pinging another device (192.168.2.54) on that same network that should always be online...

    http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_09_02.html
    'sleep' in the script should always return with an exit status of zero - so there is no reason for the loop to stop...

    Will leave the rest of the commands in the script as homework for you to decipher :-)
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 02 2016, 07:57 PM - #Permalink
    Resolved
    0 votes
    Unfortunately I've just had a message back to say there are too many errors in the sources for the ElRepo guys to be able to produce an e1000 driver for ClearOS 7.x.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 02 2016, 08:16 PM - #Permalink
    Resolved
    0 votes
    That's a shame, Nick.

    I think i will replace the e1000, because it is giving errors almost every 5 minuts.

    Any suggestion which will work with ClearOS7
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 02 2016, 09:12 PM - #Permalink
    Resolved
    0 votes
    Presumably you have a PCI system or is it a mixed PCI/PCI-E? I think RTL-8169 PCI cards are OK, but I don't know much about any of them. PCI will struggle to get full speed on gigabit links because of the PCI bandwidth. PCI-E is better, but for a multi-port card you should use an x4 or greater slot.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, June 03 2016, 12:33 AM - #Permalink
    Resolved
    0 votes
    Patrick - I have several E1000 NICs and only one is giving the problem I described, and that only happens once every several days. Have used r8169 NICs and they work fine - just don't mix them with a system that has r8168 based NICs unless you want fun and games. Wonder if your NIC is actually broken or there is some other problem...
    The reply is currently minimized Show
Your Reply