Bug 2002344

FWIW, it's actually also blocking CentOS CI infra, as the hardware we have is using e1000 nic https://pagure.io/centos-infra/issue/441
We also got some people asking why they couldn't install CentOS Stream 9 through vmware workstation, only to figure out that it's the emulated nic , instead of the vmxnet3 one (which is better and works)

In RHEL 8, the driver is enabled, with the following RHEL-specific addition in e1000_init_module():

        add_taint(TAINT_SUPPORT_REMOVED, LOCKDEP_STILL_OK);
        pr_warn("E1000 MODULE IS NOT SUPPORTED\n");

IF we enable it for RHEL 9, there needs to be something similar.
The mptsas driver in RHEL 9 does it too, see drivers/message/fusion/mptsas.c:mptsas_probe(), added by commit c2b3035917b85 ("mptsas: Taint kernel if mptsas is loaded"):

#ifdef CONFIG_RHEL_DIFFERENCES
        add_taint(TAINT_SUPPORT_REMOVED, LOCKDEP_STILL_OK);
        pr_warn("MPTSAS MODULE IS NOT SUPPORTED\n");
#endif

https://www.intel.com/content/www/us/en/support/articles/000026530/ethernet-products/legacy-ethernet-products.html

It looks like there might be a handful of e1000 cards young enough to still qualify for Intel's 5-year warranty...but not many...

Re: comment 1, my personal advice would be for someone to buy a new NIC and stuff it in that CI server.

(In reply to John W. Linville from comment #10)
> https://www.intel.com/content/www/us/en/support/articles/000026530/ethernet-
> products/legacy-ethernet-products.html
> 
> It looks like there might be a handful of e1000 cards young enough to still
> qualify for Intel's 5-year warranty...but not many...
> 
> Re: comment 1, my personal advice would be for someone to buy a new NIC and
> stuff it in that CI server.

Well, we have 256 seamicro compute nodes/cards in 4 chassis ( 4*64 compute nodes), all using that onboard nic and no way to replace it .. :)
but I get your point. if there is no way to enable it, we'll have to decide if we want to not offer stream9 tests for projects (like rdo/openstack/ovirt/gluster, etc) or if someone can then sponsor replacement hardware (all out of warranty) , but not something I have to decide, I'll just be messenger

Don't mind me -- I may be grumpy about it, but this is out of my hands as well. ;-)

Ran and verified tier1 and tier2 tests for kernel version 5.14.0-1.el9.x86_64

Following tests are run

/kernel/networking/nic/sanity_check
/kernel/networking/nic/functions/packet_statistics 
/kernel/networking/nic/functions/link_check 
/kernel/networking/nic/functions/ring 
/kernel/networking/nic/functions/offload 
/kernel/networking/nic/functions/multiqueue
/kernel/networking/nic/functions/devlink 
/kernel/networking/nic/functions/scaling 
/kernel/networking/nic/functions/stress
/kernel/networking/nic/functions/abnormal
/kernel/networking/nic/functions/specific 
/kernel/networking/nic/functions/vlan_geneve
/kernel/networking/nic/functions/vlan_vxlan
/kernel/networking/nic/functions/topo_reboot
/kernel/networking/nic/functions/wol
/kernel/networking/nic/functions/coalesce 
/kernel/networking/nic/functions/pause 
/kernel/networking/nic/functions/hashkey 
/kernel/networking/nic/functions/ethtool/Regression 
/kernel/networking/nic/functions/ethtool/sanity
/kernel/networking/nic/functions/nic_driver_load 
/kernel/networking/netperf/regular_netperf

Just for my own planning (centos infra), can we get an ETA when it will be enabled for Stream 9 kernel ? The kernel versions available on https://kojihub.stream.centos.org/koji/packageinfo?packageID=800 are either lower or higher so I guess the you mention was branched off for rhel9 itself .. but I guess it should be then reflected in stream itself ?

(In reply to farrotin from comment #30)
> Just for my own planning (centos infra), can we get an ETA when it will be
> enabled for Stream 9 kernel ? The kernel versions available on
> https://kojihub.stream.centos.org/koji/packageinfo?packageID=800 are either
> lower or higher so I guess the you mention was branched off for rhel9 itself
> .. but I guess it should be then reflected in stream itself ?

It's been already merged to stream 9 kernel:
  https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/commit/d334fb74543bacbec67428b69a6c55a75d2d7cc5
so I estimate couple days until Herton runs next build.

(In reply to Jan Stancek from comment #31)
> 
> It's been already merged to stream 9 kernel:
>  
> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/commit/
> d334fb74543bacbec67428b69a6c55a75d2d7cc5
> so I estimate couple days until Herton runs next build.

Thanks a lot ! really looking forward to test from a next compose with that kernel and then unblock the stream 9 tests behind ci.centos.org

Status update : I see that now we have a kernel that was built on Stream koji : https://kojihub.stream.centos.org/koji/buildinfo?buildID=14663
from the changelog :

- Enable e1000 in rhel9 as unsupported (Ken Cox) [2002344]

So let's test from a compose (https://composes.stream.centos.org/development/latest-CentOS-Stream/compose/BaseOS/x86_64/os/) and see if that works.
Can give some feedback here and then ask Stream team to also have compose pushed as "official" one and so landing on mirror.stream.centos.org (and everywhere else)

I confirm that it works now from that compose : was able to deploy Stream 9 : 

uname -a ; modinfo e1000|egrep 'filename|description|rhelversion'
Linux test-9s.ci.centos.org 5.14.0-6.el9.x86_64 #1 SMP Fri Oct 8 20:23:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
filename:       /lib/modules/5.14.0-6.el9.x86_64/kernel/drivers/net/ethernet/intel/e1000/e1000.ko.xz
description:    Intel(R) PRO/1000 Network Driver
rhelversion:    9.0

I'll ask Brian Stinson about when that compose will switch from 'development' to 'production' and so rolled out to mirror.stream.centos.org network (and third-party mirrors fetching from there)

I see that it landed on mirror.stream.centos.org and so I think this request can now be closed ?

(In reply to farrotin from comment #35)
> I see that it landed on mirror.stream.centos.org and so I think this request
> can now be closed ?

I think it'll be auto-closed once 9-Beta is released and errata is closed/released. This is a 9-Beta bug where changes were synced/merged up to CentOS.