Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1081362

Summary: RHEL 7.0 unable to identify network card Realtek 8211 series - which was ok in RHEL6
Product: Red Hat Enterprise Linux 7 Reporter: Prosun Prodhan <linuxprosun>
Component: kernelAssignee: John Greene <jogreene>
kernel sub component: NIC Drivers QA Contact: Yulong Pei <ypei>
Status: CLOSED INSUFFICIENT_DATA Docs Contact:
Severity: high    
Priority: unspecified CC: ajb, dcbw, jfeeney, linuxprosun, toracat
Version: 7.0   
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-13 19:03:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of lsmod
none
dmesg of RHEL7b
none
lspci output none

Description Prosun Prodhan 2014-03-27 04:47:13 UTC
Created attachment 879299 [details]
output of lsmod

Description of problem: While installing RHEL7.0beta to M4N68T-M LE V2 systems, the onboard ethernet controller (RTL 8211 series) wont work. But it working fine with RHEL6.0.


Version-Release number of selected component (if applicable): RTL 8211


How reproducible: Just install RHEL7.0b on using this mobo, and it will not be able to find the NIC


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Dan Williams 2014-03-28 22:44:21 UTC
Please attach the output of the 'lspci' and 'dmesg' commands, thanks!

Comment 3 Prosun Prodhan 2014-03-29 13:03:26 UTC
Created attachment 880123 [details]
dmesg of RHEL7b

Comment 4 Prosun Prodhan 2014-03-29 13:07:44 UTC
Created attachment 880125 [details]
lspci output

lspci output. The problem is related to on-board (ASUS M4N68T series) ethernet chip. Now I am searching for any extra (PCI slot) ethernet card having the same (RTL8111) series chip, to find if works or not. Till date not able to find the card.

Also informed ASUS tech team - regarding the fact. They just replied that they have escalated to proper channel. But if RHEL7final released without solving the bug, then our around 30 PC will not be able to accept RHEL7.

Comment 5 RHEL Program Management 2014-04-06 05:47:13 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 6 Akemi Yagi 2014-07-15 12:49:58 UTC
lspci shows this ethernet:

00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)

It will help if you show us the output of 'lspci -nn' because that includes the device IP pairings.

I suspect the device in question uses the forcedeth driver (but this needs confirmation with the IDs). If so, this is one of the many drivers that are now disabled in RHEL 7 [1].

One temporary solution will be to use the kmod-forcedeth package from ELRepo [2]. 


[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Removed_Packages.html#sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Removed_Packages-Removed_Drivers

[2] http://elrepo.org/tiki/kmod-forcedeth

Comment 7 John Greene 2014-07-15 14:07:35 UTC
We do need that lspci -nn to insure the below is accurate, but assuming it is for the the forcedeth.ko module.

I checked rhel6 and rhel7 trees.  
The .config in RHEL6 does indeed enable that device by default:
CONFIG_FORCEDETH=m
CONFIG_FORCEDETH_NAPI=y

But it's, BY DEFAULT, disabled in RHEL7.  The driver does still exist in the rhel7 source tree and you can pretty easily build a kernel with it enabled if you wish.  The driver source in the RHEL7 tree is located in

drivers/net/ethernet/nvidia/
The Kconfig in that directory tell you what to do to change the .config for a kernel build to include it.

But, sent us the lspci -nn output to be sure!

Comment 8 Akemi Yagi 2014-07-15 15:34:29 UTC
(In reply to John Greene from comment #7)

> But it's, BY DEFAULT, disabled in RHEL7.  The driver does still exist in the
> rhel7 source tree and you can pretty easily build a kernel with it enabled
> if you wish.

Yes, but you do not need to build the whole kernel. You can build just the forcedeth kernel module. That's exactly what ELRepo did to produce the kmod-forcedeth package. As a bonus, because it is kABI-tracking, it survives kernel updates transparently. I think this is the best/easiest solution at this moment.

By the way a kernel with forcedeth enabled will be available from CentOS as the "centosplus" kernel [1] if anyone prefers that way as an interim solution.

[1] http://bugs.centos.org/view.php?id=7359

Comment 9 John Greene 2015-03-13 19:03:12 UTC
(In reply to John Greene from comment #7)
> We do need that lspci -nn to insure the below is accurate, but assuming it
> is for the the forcedeth.ko module.

> But, sent us the lspci -nn output to be sure!

I'm not aware of any change in soon to be available 7.1 RHEL for this but I'd give it a try.  Since I haven't seen anything in the way of the requested lspci -nnv to help you I'm closing this due to age.  Please reopen if you have further information that would help us help you.

Comment 10 Red Hat Bugzilla 2023-09-14 02:05:38 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days