Patches for 5.6 & 5.7

[satmandu]

For what it is worth, this is the patch for 3.6.0 I used to get this to work with the kernel 5.6rc series using Ubuntu Mainline kernels. This works to compile mainline kernels for 5.5 too.

--- a/dkms.conf 1969-12-31 19:00:00.000000000 -0500
+++ b/dkms.conf 2020-03-02 11:24:24.264495720 -0500
@@ -0,0 +1,9 @@
+PACKAGE_NAME="e1000e"
+PACKAGE_VERSION="3.6.0"
+AUTOINSTALL=yes
+MAKE[0]="cd src/ && (if [[ $kernelver == *\"rc\"* ]] || [[ $(echo $kernelver| cut -d- -f2) -ge "255" ]]; then sed -i 's/UTS_UBUNTU_RELEASE_ABI/UTS_UBUNTU_RELEASE_ABI_OVERRIDE/g' kcompat.h && export abi_override=14; fi && make CFLAGS=-DUTS_UBUNTU_RELEASE_ABI_OVERRIDE=$abi_override KVERSION=$kernelver BUILD_KERNEL=$kernelver)"
+CLEAN="cd src/ && make clean"
+BUILT_MODULE_NAME="e1000e"
+BUILT_MODULE_LOCATION="src/"
+DEST_MODULE_LOCATION="/kernel/drivers/net/ethernet/intel/e1000e"
+REMAKE_INITRD="yes"
diff -Npaur a/src/kcompat.h b/src/kcompat.h
--- a/src/kcompat.h 2019-09-09 14:28:11.384088231 -0400
+++ b/src/kcompat.h 2020-03-01 23:20:12.945164453 -0500
@@ -2796,7 +2796,11 @@ void _kc_pci_disable_link_state(struct p
 #define pci_disable_link_state(p, s) _kc_pci_disable_link_state(p, s)
 #else /* < 2.6.26 */
 #define NETDEV_CAN_SET_GSO_MAX_SIZE
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)
+#include <linux/pci.h>
+#else
 #include <linux/pci-aspm.h>
+#endif
 #define HAVE_NETDEV_VLAN_FEATURES
 #ifndef PCI_EXP_LNKCAP_ASPMS
 #define PCI_EXP_LNKCAP_ASPMS 0x00000c00    /* ASPM Support */
diff -Npaur a/src/netdev.c b/src/netdev.c
--- a/src/netdev.c  2019-09-09 14:28:11.384088231 -0400
+++ b/src/netdev.c  2020-03-02 11:29:40.277173053 -0500
@@ -6675,7 +6675,11 @@ static netdev_tx_t e1000_xmit_frame(stru
  * e1000_tx_timeout - Respond to a Tx Hang
  * @netdev: network interface device structure
  **/
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0)
+static void e1000_tx_timeout(struct net_device *netdev, unsigned int txqueue)
+#else
 static void e1000_tx_timeout(struct net_device *netdev)
+#endif
 {
    struct e1000_adapter *adapter = netdev_priv(netdev);

[rhardy613]

Nice! It would be really good to post this upstream so Intel can fix their code. Would you please? At least if you posted under patches on source forge other users wouldn't have to figure out how to fix the code.

[satmandu]

This compiles for 5.7, but it does not work for 5.7. :/

diff -Npaur a/dkms.conf b/dkms.conf
--- a/dkms.conf 1969-12-31 19:00:00.000000000 -0500
+++ b/dkms.conf 2020-04-20 12:31:32.526941298 -0400
@@ -0,0 +1,9 @@
+PACKAGE_NAME="e1000e"
+PACKAGE_VERSION="3.6.0"
+AUTOINSTALL=yes
+MAKE[0]="cd src/ && (if [[ $kernelver == *\"rc\"* ]] || [[ $(echo $kernelver| cut -d- -f2) -ge "255" ]]; then sed -i 's/UTS_UBUNTU_RELEASE_ABI/UTS_UBUNTU_RELEASE_ABI_OVERRIDE/g' kcompat.h && export abi_override=14; fi && make W=0 CFLAGS=-DUTS_UBUNTU_RELEASE_ABI_OVERRIDE=$abi_override KVERSION=$kernelver BUILD_KERNEL=$kernelver)"
+CLEAN="cd src/ && make clean"
+BUILT_MODULE_NAME="e1000e"
+BUILT_MODULE_LOCATION="src/"
+DEST_MODULE_LOCATION="/kernel/drivers/net/ethernet/intel/e1000e"
+REMAKE_INITRD="yes"
diff -Npaur a/src/kcompat.h b/src/kcompat.h
--- a/src/kcompat.h 2019-09-09 14:28:11.384088231 -0400
+++ b/src/kcompat.h 2020-04-20 12:59:11.582750232 -0400
@@ -2796,7 +2796,11 @@ void _kc_pci_disable_link_state(struct p
 #define pci_disable_link_state(p, s) _kc_pci_disable_link_state(p, s)
 #else /* < 2.6.26 */
 #define NETDEV_CAN_SET_GSO_MAX_SIZE
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)
+#include <linux/pci.h>
+#else
 #include <linux/pci-aspm.h>
+#endif
 #define HAVE_NETDEV_VLAN_FEATURES
 #ifndef PCI_EXP_LNKCAP_ASPMS
 #define PCI_EXP_LNKCAP_ASPMS 0x00000c00    /* ASPM Support */
@@ -6753,4 +6757,10 @@ static inline void skb_frag_off_add(skb_
 #define __flow_indr_block_cb_unregister __tc_indr_block_cb_unregister
 #endif /* 5.4.0 */

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 7, 0)
+#define CPU_LATENCY_QOS
+#define NO_PM_QOS_CPU_DMA_LATENCY
+#define HAVE_PCI_AER_CLEAR
+#endif /* 5.7.0 */
+
 #endif /* _KCOMPAT_H_ */
diff -Npaur a/src/netdev.c b/src/netdev.c
--- a/src/netdev.c  2019-09-09 14:28:11.384088231 -0400
+++ b/src/netdev.c  2020-04-20 12:58:43.630808596 -0400
@@ -3711,7 +3711,9 @@ static void e1000_configure_rx(struct e1

            ew32(RXDCTL(0), rxdctl | 0x3);
        }
-#ifdef HAVE_PM_QOS_REQUEST_LIST_NEW
+#ifdef CPU_LATENCY_QOS
+       cpu_latency_qos_update_request(&adapter->pm_qos_req, lat);
+#elif defined(HAVE_PM_QOS_REQUEST_LIST_NEW)
        pm_qos_update_request(&adapter->pm_qos_req, lat);
 #elif defined(HAVE_PM_QOS_REQUEST_LIST)
        pm_qos_update_request(&adapter->pm_qos_req, lat);
@@ -3720,7 +3722,10 @@ static void e1000_configure_rx(struct e1
                      adapter->netdev->name, lat);
 #endif
    } else {
-#ifdef HAVE_PM_QOS_REQUEST_LIST_NEW
+#ifdef CPU_LATENCY_QOS
+       cpu_latency_qos_update_request(&adapter->pm_qos_req,
+                    PM_QOS_DEFAULT_VALUE);
+#elif defined(HAVE_PM_QOS_REQUEST_LIST_NEW)
        pm_qos_update_request(&adapter->pm_qos_req,
                      PM_QOS_DEFAULT_VALUE);
 #elif defined(HAVE_PM_QOS_REQUEST_LIST)
@@ -5181,6 +5186,7 @@ int e1000e_open(struct net_device *netde

 #endif
    /* DMA latency requirement to workaround jumbo issue */
+#ifndef NO_PM_QOS_CPU_DMA_LATENCY
 #ifdef HAVE_PM_QOS_REQUEST_LIST_NEW
    pm_qos_add_request(&adapter->pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
               PM_QOS_DEFAULT_VALUE);
@@ -5191,6 +5197,7 @@ int e1000e_open(struct net_device *netde
    pm_qos_add_requirement(PM_QOS_CPU_DMA_LATENCY, adapter->netdev->name,
                   PM_QOS_DEFAULT_VALUE);
 #endif
+#endif

    /* before we allocate an interrupt, we must be ready to handle it.
     * Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
@@ -5235,7 +5242,9 @@ int e1000e_open(struct net_device *netde
    return 0;

 err_req_irq:
-#ifdef HAVE_PM_QOS_REQUEST_LIST_NEW
+#ifdef CPU_LATENCY_QOS
+   cpu_latency_qos_remove_request(&adapter->pm_qos_req);
+#elif defined(HAVE_PM_QOS_REQUEST_LIST_NEW)
    pm_qos_remove_request(&adapter->pm_qos_req);
 #elif defined(HAVE_PM_QOS_REQUEST_LIST)
    pm_qos_remove_request(&adapter->pm_qos_req);
@@ -5322,7 +5331,9 @@ int e1000e_close(struct net_device *netd
        !test_bit(__E1000_TESTING, &adapter->state))
        e1000e_release_hw_control(adapter);

-#ifdef HAVE_PM_QOS_REQUEST_LIST_NEW
+#ifdef CPU_LATENCY_QOS
+   cpu_latency_qos_remove_request(&adapter->pm_qos_req);
+#elif defined(HAVE_PM_QOS_REQUEST_LIST_NEW)
    pm_qos_remove_request(&adapter->pm_qos_req);
 #elif defined(HAVE_PM_QOS_REQUEST_LIST)
    pm_qos_remove_request(&adapter->pm_qos_req);
@@ -6675,7 +6686,11 @@ static netdev_tx_t e1000_xmit_frame(stru
  * e1000_tx_timeout - Respond to a Tx Hang
  * @netdev: network interface device structure
  **/
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0)
+static void e1000_tx_timeout(struct net_device *netdev, unsigned int txqueue)
+#else
 static void e1000_tx_timeout(struct net_device *netdev)
+#endif
 {
    struct e1000_adapter *adapter = netdev_priv(netdev);

@@ -8033,7 +8048,11 @@ static pci_ers_result_t e1000_io_slot_re
        result = PCI_ERS_RESULT_RECOVERED;
    }

+#ifdef HAVE_PCI_AER_CLEAR
+   pci_aer_clear_nonfatal_status(pdev);
+#else
    pci_cleanup_aer_uncorrect_error_status(pdev);
+#endif

    return result;
 }

[rhardy613]

I haven't been able to try this yet. Does it work for 5.5.x? I'm having Intel driver grief on many levels with Ubuntu 19.10: I219-V NICs that don't work without this driver, having to disabling half a dozen features to get performance and now i915 video hangs. This is the last kernel that doesn't hang on Ubuntu 19.10: hi linux-image-5.3.0-45-generic 5.3.0-45.37 amd64 Signed kernel image generic

[satmandu]

I haven't been able to try this yet. Does it work for 5.5.x? It does work for 5.5 & 5.6 with the patch at the top. (Assuming you're talking about the ubuntu mainline kernels.)

I have used it with Ubuntu 20.04 just fine. (It's close enough to release that I'm not worried about using a beta at this point.)

The 5.4 kernels which are default with 20.04 aren't giving me any problems with my i915 skylake setup.

[rhardy613]

I've got a Intel Core i3-8100 CPU aka Coffee Lake and it had been super stable up until 5.3.0-46 where it is completely unusable. I get a hang every two minutes. From the launchpad bug 1872001 it seems either a kernel patch in the 5.3.x series with fix it or I'll need to wait for 5.5 but dragons lie down on the 5.4.x path currently.

[satmandu]

You should see if the 5.6 mainline kernels fix it: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

[rhardy613]

That ended up being more complicated than expected as I need the extras that apparently aren't present in the mainline kernels... Nothing is simple these days...

[satmandu]

You can always compile your own kernel.

I've been compiling them for 2 decades or so... It has gotten much easier. 😅

[rhardy613]

I did that for decades when running vanilla aka mainline kernels with my own custom patch sets was needed. With DKMS I really hope that isn't needed again... Custom kernels are very time consuming and not convenient especially when security patches are released regularly. I've been working with Intel engineering to try to get these patches committed upstream and a new release issued. We need to get at least 5.4 and 5.6 fixed upstream. If they can manage a 5.7 one that would be great but it seems unlikely until 5.7 is out of RC.

[rhardy613]

Working with Intel we managed to get Intel to release an updated driver for the e1000e. They have just released 3.8.4. Anyone feel like updating the dkms package with it?

[rhardy613]

3.8.4 is a big improvement but still had some performance issues on my systems. I've pushed it back to engineering for a 2nd pass. Would it be possible to get this package added to Debian Universe? That way it could be made available to end users on Ubuntu. I've got more information on the process but it seems to be dependent on either becoming a Debian developer or finding one to work with...

[satmandu]

@rhardy613 Why not just setup a ppa if you want to get it to ubuntu users? Much easier path, no?

[satmandu]

Here is a patch for 3.8.4 to compile for rc kernels:

diff -Npaur a/dkms.conf b/dkms.conf
--- a/dkms.conf 2020-04-23 11:20:57.491817381 -0400
+++ b/dkms.conf 2020-04-23 11:24:58.721689683 -0400
@@ -1,6 +1,6 @@
 PACKAGE_NAME="e1000e"
 PACKAGE_VERSION="3.8.4"
-MAKE[0]="cd src/ && make KVERSION=$kernelver BUILD_KERNEL=$kernelver"
+MAKE[0]="cd src/ && (if [[ $kernelver == *\"rc\"* ]] || [[ $(echo $kernelver| cut -d- -f2) -ge "255" ]]; then sed -i 's/UTS_UBUNTU_RELEASE_ABI/UTS_UBUNTU_RELEASE_ABI_OVERRIDE/g' kcompat.h && export abi_override=14; fi && make CFLAGS=-DUTS_UBUNTU_RELEASE_ABI_OVERRIDE=$abi_override KVERSION=$kernelver BUILD_KERNEL=$kernelver)"
 CLEAN="cd src/ && make clean"
 BUILT_MODULE_NAME[0]="e1000e"
 BUILT_MODULE_LOCATION[0]="src/"

Note same issue exists with not compiling for 5.7 kernels:

DKMS make.log for e1000e-3.8.4 for kernel 5.7.0-050700rc2-generic (x86_64)
Thu 23 Apr 2020 11:25:09 AM EDT
*** The target kernel has CONFIG_MODULE_SIG_ALL enabled, but
*** the signing key cannot be found. Module signing has been
*** disabled for this build.
make[1]: Entering directory '/usr/src/linux-headers-5.7.0-050700rc2-generic'
  CC [M]  /var/lib/dkms/e1000e/3.8.4/build/src/netdev.o
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c: In function ‘e1000_configure_rx’:
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:3714:3: error: implicit declaration of function ‘pm_qos_update_request’; did you mean ‘freq_qos_update_request’? [-Werror=implicit-function-declaration]
 3714 |   pm_qos_update_request(&adapter->pm_qos_req, lat);
      |   ^~~~~~~~~~~~~~~~~~~~~
      |   freq_qos_update_request
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c: In function ‘e1000e_open’:
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:5189:2: error: implicit declaration of function ‘pm_qos_add_request’; did you mean ‘freq_qos_add_request’? [-Werror=implicit-function-declaration]
 5189 |  pm_qos_add_request(&adapter->pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
      |  ^~~~~~~~~~~~~~~~~~
      |  freq_qos_add_request
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:5189:43: error: ‘PM_QOS_CPU_DMA_LATENCY’ undeclared (first use in this function)
 5189 |  pm_qos_add_request(&adapter->pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
      |                                           ^~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:5189:43: note: each undeclared identifier is reported only once for each function it appears in
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:5243:2: error: implicit declaration of function ‘pm_qos_remove_request’; did you mean ‘freq_qos_remove_request’? [-Werror=implicit-function-declaration]
 5243 |  pm_qos_remove_request(&adapter->pm_qos_req);
      |  ^~~~~~~~~~~~~~~~~~~~~
      |  freq_qos_remove_request
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c: In function ‘e1000_io_slot_reset’:
/var/lib/dkms/e1000e/3.8.4/build/src/netdev.c:8100:2: error: implicit declaration of function ‘pci_cleanup_aer_uncorrect_error_status’ [-Werror=implicit-function-declaration]
 8100 |  pci_cleanup_aer_uncorrect_error_status(pdev);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:267: /var/lib/dkms/e1000e/3.8.4/build/src/netdev.o] Error 1
make[1]: *** [Makefile:1722: /var/lib/dkms/e1000e/3.8.4/build/src] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.7.0-050700rc2-generic'
make: *** [Makefile:73: default] Error 2

Here's what I did to get this setup on my ubuntu system before the above patch:

cd /usr/src
sudo git clone --depth=1 https://github.com/koljah-de/e1000e-dkms-debian
sudo ln -s e1000e-dkms-debian/e1000e-dkms/usr/src/e1000e-3.8.4 e1000e-3.8.4
sudo dkms add e1000e/3.8.4
sudo dkms build e1000e/3.8.4

[satmandu]

(Also 3.8.4 seems to build just fine on kernel 5.6.x systems)

[rhardy613]

PPA is a work around but isn't good enough. We are having users leave Ubuntu/Debian because they cannot get their network cards working. I'm trying to get to the point that a user will be able to just go apt-get install e1000e-dkms and it will pick it up the functional driver. To do that we need to get it into Universe on Debian. Intel Engineering won't address that until 5.7 is released unfortunately... Any idea when that is expected? If we are on 5.7-rc2 it can't be too long...

[rhardy613]

The ideal scenario would be having the stable driver in the kernel but baby steps....

[rhardy613]

It seems they have moved 3-4 functions around pm_qos_remove_request is gone from 5.7-rc1 and 5.7-rc2 but is present in 5.6.7. See this kernel source search I suspect if we diff include/linux/pm_qos.h, between 5.6.7 and 5.7-rc2 we could figure out the changes and fix the patch.

[rhardy613]

I think I found the documentation on the calls. These are pm_qos calls in the 5.6 kernel and these are pm_qos calls in the 5.7 kernel basically on the calls that are that are getting implicit declaration I would do a conditional change in the call applying a s/pmqos/cpu_latencyqos/ substitution on the calls.

[rhardy613]

I could probably hack that patch if I had somewhere I could work on it... I suspect Intel Engineering might be more likely to push out another update if we sent them a working patch that fixed 5.7.

[satmandu]

@rhardy613 I tried to make a patch for 5.7 using the earlier source up above at https://github.com/koljah-de/e1000e-dkms-debian/issues/5#issuecomment-616691373, but though it compiles fine, it doesn't actually work. The interface never shows up...

[rhardy613]

It is clear from your compile errors that your patch is missing required structure changes which were made in the kernel between 5.6.7 and 5.7-rc1. Without those changes your patch will not work on 5.7 kernels. While the code isn't identical I just realized that it should be close enough that would should be able to look at how the e1000e code in the kernel changed between 5.6.7 and 5.7-rc1 (or 5.7-rc2 possibly) and make those same changes on this driver.

From the compile errors is seems clear there are only four key functions which have changed names i.e. pm_qos_update_request, pm_qos_add_request , pm_qos_remove_request, pci_cleanup_aer_uncorrect_error_status. It's a matter of looking a diff of the driver code between kernel driver for e1000e on 5.6.7 and 5.7-rc1 and seeing how they changes the calls so the native kernel driver would keep working. I really doubt it will be major surgery but I haven't looked yet. How are you building those later kernels anyways? I could put 20.04 on a VM. Do I just put a mainline kernel on that VM and try the DKMS build you mentioned above? Once the driver works on 5.7 we can figure out the conditional syntax to make it build on both pre 5.7 kernels and post 5.7 kernels. It's probably going to be similar to what the conditional code that is already in your patch.

[rhardy613]

It is always possible that we fix those four renamed functions and more will show up but the e1000e related diff between the two kernels should show this.

[rhardy613]

I believe that:

• pm_qos_update_request has been replaced with cpu_latency_qos_update_request
• pm_qos_add_request has been replaced with cpu_latency_qos_add_request
• pm_qos_remove_request has been replaced with cpu_latency_qos_remove_request
• pci_cleanup_aer_uncorrect_error_status I haven't found the replacement yet but the diff should identify it.

[rhardy613]

This shows the v5.7-rc2 netdev.c code This shows this shows the v5.6 netdev.c code

[rhardy613]

It seems the pci_cleanup_aer_uncorrect_error_status has been replaced with pci_aer_clear_nonfatal_status with the same arguments but this does not appear at all the 5.7-rc2 e1000e kernel driver code. I suspect this would be more complicated that expected to implement...

[satmandu]

That's why I had

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 7, 0)
+#define CPU_LATENCY_QOS
+#define NO_PM_QOS_CPU_DMA_LATENCY
+#define HAVE_PCI_AER_CLEAR
+#endif /* 5.7.0 */
+

and also

+#ifdef HAVE_PCI_AER_CLEAR
+   pci_aer_clear_nonfatal_status(pdev);
+#else
    pci_cleanup_aer_uncorrect_error_status(pdev);
+#endif

[rhardy613]

Ah ok the last patch I can see posted on here for 3.8.4 only shows me the DKMS chunk starting with diff -Npaur a/dkms.conf b/dkms.conf So if I'm understanding correctly after tweaking things so all the error: implicit declaration go away during compile the interface still doesn't show up when the module is loaded? If that's the case and we can't figure out why we may have to wait. Alternatively someone with more recent kernel hacking skills, for example a kernel hacker on an IRC channel or developer channel might be able to see what we are missing. The kernel code seems quite different than the DKMS e1000e driver code.

[ohquait]

That's why I had

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 7, 0)
+#define CPU_LATENCY_QOS
+#define NO_PM_QOS_CPU_DMA_LATENCY
+#define HAVE_PCI_AER_CLEAR
+#endif /* 5.7.0 */
+

and also

+#ifdef HAVE_PCI_AER_CLEAR
+ pci_aer_clear_nonfatal_status(pdev);
+#else
  pci_cleanup_aer_uncorrect_error_status(pdev);
+#endif

@satmandu can you compile this driver on kernel-5.8.3 and gcc-10.2.0 ?

DKMS make.log for e1000e-3.8.4-4pclos2020 for kernel 5.8.3-pclos1 (x86_64) Mon 24 Aug 2020 11:57:15 AM UTC make[1]: Entering directory '/usr/src/kernel-devel-5.8.3-pclos1' CC [M] /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/netdev.o In file included from /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/e1000.h:14, from /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/netdev.c:30: /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/kcompat.h: In function ‘kc_xdp_umem_get_data’: /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/kcompat.h:6698:38: error: ‘(umem->pgs + (sizetype)((addr >> 12) 8))’ is a pointer; did you mean to use ‘->’? 6698 | return umem->pgs[addr >> PAGE_SHIFT].addr + (addr & (PAGE_SIZE - 1)); | ^ | -> /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/kcompat.h: In function ‘kc_xdp_umem_get_dma’: /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/kcompat.h:6706:38: error: ‘(umem->pgs + (sizetype)((addr >> 12) 8))’ is a pointer; did you mean to use ‘->’? 6706 | return umem->pgs[addr >> PAGE_SHIFT].dma + (addr & (PAGE_SIZE - 1)); | ^ | -> make[2]: [scripts/Makefile.build:281: /var/lib/dkms/e1000e/3.8.4-4pclos2020/build/netdev.o] Error 1 make[1]: [Makefile:1747: /var/lib/dkms/e1000e/3.8.4-4pclos2020/build] Error 2 make[1]: Leaving directory '/usr/src/kernel-devel-5.8.3-pclos1' make: *** [Makefile:88: default] Error 2

[satmandu]

Haven't tried. Having success with the built-in module on 5.8.3.

On Mon, Aug 24, 2020, 4:31 AM ohquait notifications@github.com wrote:

That's why I had

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 7, 0) +#define CPU_LATENCY_QOS +#define NO_PM_QOS_CPU_DMA_LATENCY +#define HAVE_PCI_AER_CLEAR +#endif / 5.7.0 / +

and also

+#ifdef HAVE_PCI_AER_CLEAR

• pci_aer_clear_nonfatal_status(pdev); +#else pci_cleanup_aer_uncorrect_error_status(pdev); +#endif

@satmandu https://github.com/satmandu can you compile this driver on kernel-5.8.3 and gcc-10.2.0 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/koljah-de/e1000e-dkms-debian/issues/5#issuecomment-678987584, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAILX7PWUXIBTZ7N24G46BTSCIQONANCNFSM4K7MESCQ .

[ohquait]

Thank you for the information, i will not searching for patches or rebuild this dkms anymore. stay healthy !