Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Unable to get Onboard Intel NiC working [Solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
tabanus
l33t
l33t


Joined: 11 Jun 2004
Posts: 626
Location: UK

PostPosted: Fri Feb 23, 2018 4:45 pm    Post subject: Unable to get Onboard Intel NiC working [Solved] Reply with quote

I built a Ryzen system using 2400G

Many problems with the onboard graphics, so I've installed a Radeon R5 230 graphics card.

This caused a kernel panic on boot, which I've worked around by disabling IOMMU in BIOS.

Now the onboard ethernet adapter won't work. It's an intel I211AT Gigabit LAN, and was working fine without the external graphics card, and other than the kernel options and firmware for the graphics, I hadn't changed any kernel configs.

The network does work when booting System rescue CD or Ubuntu from a USB.

I tried just including all the intel ethernet drivers, but that's not helped either.

My kernel config
_________________
Things you might say if you never took Physics: "I'm overweight even though I don't overeat." - Neil deGrasse Tyson


Last edited by tabanus on Fri Feb 23, 2018 6:53 pm; edited 1 time in total
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7081
Location: Saint Amant, Acadiana

PostPosted: Fri Feb 23, 2018 5:05 pm    Post subject: Reply with quote

Boot from Sysrescue and do lspci -k, it will show what driver is in use.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5618
Location: Removed by Neddy

PostPosted: Fri Feb 23, 2018 5:06 pm    Post subject: Reply with quote

whats the output of lspci -vvv && ifconfig -a
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
tabanus
l33t
l33t


Joined: 11 Jun 2004
Posts: 626
Location: UK

PostPosted: Fri Feb 23, 2018 6:53 pm    Post subject: Reply with quote

Naib wrote:
whats the output of lspci -vvv && ifconfig -a


Code:
enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
        ether 2c:fd:a1:59:67:09  txqueuelen 1000  (Ethernet)
        RX packets 1230  bytes 1196825 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1063  bytes 114846 (112.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfe400000-fe41ffff 

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480
        sit  txqueuelen 1000  (IPv6-in-IPv4)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


When I saw this I realised the interface name has changed from enp7s0 to enp8s0. Changing the network config to reflect this has solved to problem.

So much for predictable device names :?

Thanks guys.
_________________
Things you might say if you never took Physics: "I'm overweight even though I don't overeat." - Neil deGrasse Tyson
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13758

PostPosted: Sat Feb 24, 2018 1:56 am    Post subject: Reply with quote

As I understand the "predictable" names feature, this indicates that your seemingly unrelated hardware change (adding the discrete graphics card) moved the network card to a new PCI slot, hence a new name. You describe the NIC as onboard, so presumably you cannot actually move it to a new slot. If so, this represents an interesting failure mode for the predictable names feature.
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7081
Location: Saint Amant, Acadiana

PostPosted: Sat Feb 24, 2018 2:04 am    Post subject: Reply with quote

Plug'n'play, everything is floating around. There were times one had to use jumpers to configure hardware.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5618
Location: Removed by Neddy

PostPosted: Sat Feb 24, 2018 7:54 am    Post subject: Reply with quote

tabanus wrote:
Naib wrote:
whats the output of lspci -vvv && ifconfig -a


Code:
enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
        ether 2c:fd:a1:59:67:09  txqueuelen 1000  (Ethernet)
        RX packets 1230  bytes 1196825 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1063  bytes 114846 (112.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfe400000-fe41ffff 

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480
        sit  txqueuelen 1000  (IPv6-in-IPv4)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


When I saw this I realised the interface name has changed from enp7s0 to enp8s0. Changing the network config to reflect this has solved to problem.

So much for predictable device names :?

Thanks guys.


Expect it to change again... Mine changed to eno1 (onboard1) when I updated bios with agesa 1.1.0.1 and disabled the PSP snooping device.
It took me 30seconds to figure it had changed but DAMN predictable names are meant to mitigate the crap
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1213
Location: Frankfurt, Germany

PostPosted: Sat Feb 24, 2018 8:48 am    Post subject: Reply with quote

If you want 'predictable' network interface names: start your kernel with option 'net.ifnames=0'. Your network interface will be called 'eth0' and everything will be fine.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5618
Location: Removed by Neddy

PostPosted: Sat Feb 24, 2018 8:59 am    Post subject: Reply with quote

mike155 wrote:
If you want 'predictable' network interface names: start your kernel with option 'net.ifnames=0'. Your network interface will be called 'eth0' and everything will be fine.
no, that just means "1st come 1st serve". if for some reason a piece of hardware is slow than normal IT will be bumped down hte list if you have multiple adaptors

THAT was why the predictable name scheme was introduced... rather than being based upon when the device is available its based upon WHERE the device is detected.

Quote:
Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)


So now there is a secondary side of this... how to ensure the mechanism used to classify it: onboard, pci id, mac, is PREDICTABLE... if udev messes around with which scheme to use then its a pointless waste of time such a scheme being forced onto people because it doesn't solve what it meant to
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1213
Location: Frankfurt, Germany

PostPosted: Sat Feb 24, 2018 9:24 am    Post subject: Reply with quote

Quote:
no, that just means "1st come 1st serve".

... and that's perfectly fine for most users, because most computers just have one or two network interfaces. The new network interface naming system just doesn't make much sense on those computers. That's why I start all of my servers with 'net.ifnames=0'. ;-)
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3047
Location: Illinois, USA

PostPosted: Sat Feb 24, 2018 1:39 pm    Post subject: Reply with quote

Naib wrote:
no, that just means "1st come 1st serve".

ONLY if you have more than one NIC. Most people only have one. If you have more than one, the best way is to define a udev/eudev rule assigning a name that YOU determine, based on MAC address. That's predictable. The other is a crap shoot. It's interesting to note that this ill-thought predictable name garbage is unpredictable even if only one NIC exists.

I use the net.ifnames=0. I can predict the name. It's eth0, ALWAYS eth0, no matter if I move the video card, add or remove a multimedia card or anything else. I do have one machine used as a router, It has an onbard NIC and a PCI slot NIC. eudev names the onboard (100MB) as wan0 and the PCI card (gigabit) as lan0 based on MAC addresss. I use a blue cat5e cable to the cable modem and a yellow cat 6 cable to the eight port switch. Never any confusion.

EDIT: Just wanted to add that if you have a mult-lan box, you can always name them, lan0, lan1... or mynet0, mynet1 ... or whatever. I'm not even sure if a number afterward is needed i.e firsteth, othereth, but NeddySeagoon warned me (and I always heed his advice) to not use the kernel name eth0, eth1... So use the net.inames=0 or the scheme I described in the main post. NEVER a non-euphonious name like epanada. Just would make me hungry anyway.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5618
Location: Removed by Neddy

PostPosted: Sun Feb 25, 2018 12:05 pm    Post subject: Reply with quote

Tony0945 wrote:
Naib wrote:
no, that just means "1st come 1st serve".

ONLY if you have more than one NIC. Most people only have one. If you have more than one, the best way is to define a udev/eudev rule assigning a name that YOU determine, based on MAC address. That's predictable. The other is a crap shoot. It's interesting to note that this ill-thought predictable name garbage is unpredictable even if only one NIC exists.

I use the net.ifnames=0. I can predict the name. It's eth0, ALWAYS eth0, no matter if I move the video card, add or remove a multimedia card or anything else. I do have one machine used as a router, It has an onbard NIC and a PCI slot NIC. eudev names the onboard (100MB) as wan0 and the PCI card (gigabit) as lan0 based on MAC addresss. I use a blue cat5e cable to the cable modem and a yellow cat 6 cable to the eight port switch. Never any confusion.

EDIT: Just wanted to add that if you have a mult-lan box, you can always name them, lan0, lan1... or mynet0, mynet1 ... or whatever. I'm not even sure if a number afterward is needed i.e firsteth, othereth, but NeddySeagoon warned me (and I always heed his advice) to not use the kernel name eth0, eth1... So use the net.inames=0 or the scheme I described in the main post. NEVER a non-euphonious name like epanada. Just would make me hungry anyway.

Well apparently even this new "predictable names" is flawed...

eth* en.... makes no difference to me as they are mnemonics for hardware devices... PREDICTABILITY however is more important...
I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel. This new naming was ment to mitigate this but now there is no way to predict what they will be called.

This is total BS if you ask me
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43066
Location: 56N 3W

PostPosted: Sun Feb 25, 2018 12:18 pm    Post subject: Reply with quote

Naib,

The 'Predicable Interface Names' has just swapped one set of corner cases for another.
I like the old corner cases, probably because I'm used to them :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3047
Location: Illinois, USA

PostPosted: Sun Feb 25, 2018 4:44 pm    Post subject: Reply with quote

Naib wrote:
I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel.
I would think that would exacerbate the problem. I had a similar situation once but the drivers were different, r8169 and e1000e. I would blacklist e100e and then modprobe it and execute /etc/init.d/net.eth1 later. That was when I was running pure mdev. Now I run an old version of eudev from local overlay and when I still had two cards, just made the rules I described above, naming them by mac address.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5618
Location: Removed by Neddy

PostPosted: Sun Feb 25, 2018 5:33 pm    Post subject: Reply with quote

Tony0945 wrote:
Naib wrote:
I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel.
I would think that would exacerbate the problem. I had a similar situation once but the drivers were different, r8169 and e1000e. I would blacklist e100e and then modprobe it and execute /etc/init.d/net.eth1 later. That was when I was running pure mdev. Now I run an old version of eudev from local overlay and when I still had two cards, just made the rules I described above, naming them by mac address.
I agree MAC is the more unique but you know free desktop .... lets provide 5 means to determine the interface but then not really provide a consistent means to priorities the naming convention
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3047
Location: Illinois, USA

PostPosted: Sun Feb 25, 2018 6:34 pm    Post subject: Reply with quote

Naib wrote:
I agree MAC is the more unique but you know free desktop .... lets provide 5 means to determine the interface but then not really provide a consistent means to priorities the naming convention


For sure!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum