[SOLVED] gpu causes loss of USB and network

Message

jyoung · Post by **jyoung** » Wed May 19, 2021 12:40 am

Hi Folks,

I recently tried installing a graphics card in my desktop, and I found that my USB and network ports no longer worked. I have not attempted to install the drivers for the graphics card, but it's strange that just having the hardware would cause other devices to fail. My expectation was that I'd need to mess around with drivers for a bit before I could get video working, but that's tricker without a network connection. When I removed the graphics card, the other ports returned to normal.

I'm pretty sure that the graphics card isn't faulty, since this machine is dual-booted with windows, and on the windows side everything seems normal (ports still work and the card produces video output).

The desktop is an optiplex 3050, and the card is a GT1030.

Any ideas would be welcome!

Ralphred · Post by **Ralphred** » Wed May 19, 2021 12:59 am

Does the card have a PCI power input socket, and is it attached?
Does the PSU have enough power to run the card?
As root, can we see the output of

Code: Select all

lspci -kv

please.

jyoung · Post by **jyoung** » Wed May 19, 2021 1:34 am

The card doesn't have a power input socket.

I purchased the computer and the card at Best Buy (although not together, and not at the same time), and they recommended this card for this computer, so it seems likely that there's enough power to run the card.

Later tonight I'll shutdown and install the card, and report back on that lscpi command.

jyoung · Post by **jyoung** » Wed May 19, 2021 4:43 pm

Here's the output of lspci -kv. I did some checking, and I have to correct my earlier post -- the USB ports still work with the graphics card installed, but the network connection doesn't.

Code: Select all

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05)
00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05)
00:02.0 Display controller: Intel Corporation HD Graphics 630 (rev 04)
00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller
00:14.2 Signal processing controller: Intel Corporation 200 Series PCH Thermal Subsystem
00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1
00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode]
00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 (rev f0)
00:1c.6 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #7 (rev f0)
00:1f.0 ISA bridge: Intel Corporation 200 Series PCH LPC Controller (B250)
00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset Family Power Management Controller
00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio
00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus Controller
01:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GP108 High Definition Audio Controller (rev a1)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)

jyoung · Post by **jyoung** » Mon Jul 26, 2021 12:47 am

I realize that this thread is a little old, but I did just uncover a significant clue: If I boot off a gentoo-live USB, this problem doesn't occur. So, it's not a power issue (probably). There's something about my current configuration that's causing the network interface to fail if the nvidia card is installed.

Some failed experiments: I did try installing the nvidia driver properly. The driver appears to load without issue, but this had no effect on the network interface. I also disabled the nvidia network driver, also no effect.

When I run

Code: Select all

dmesg  | grep net

on the system without the nvidia card I get

Code: Select all

[    0.079170] audit: initializing netlink subsys (disabled)
[    0.642911] igb: Intel(R) Gigabit Ethernet Network Driver
[    0.642919] Intel(R) 2.5G Ethernet Linux Driver
[    0.643004] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[    0.643043] iavf: Intel(R) Ethernet Adaptive Virtual Function Network Driver
[    0.643064] Intel(R) Ethernet Switch Host Interface Driver
[    0.643085] ice: Intel(R) Ethernet Connection E800 Series Linux Driver
[    0.652596] usbcore: registered new interface driver ums-onetouch
[    0.670766] Initializing XFRM netlink socket
[    0.671080] can: controller area network core
[    0.671088] can: netlink gateway - max_hops=1
[    0.671126] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    0.671263] 9pnet: Installing 9P2000 support
[    0.809085] printk: console [netcon0] enabled
[    0.810323] netconsole: network logging started

And with the nvidia card

Code: Select all

[    0.078996] audit: initializing netlink subsys (disabled)
[    0.638587] usbcore: registered new interface driver ums-onetouch
[    0.658233] Initializing XFRM netlink socket
[    0.658517] can: controller area network core
[    0.658525] can: netlink gateway - max_hops=1
[    0.658553] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    0.658701] 9pnet: Installing 9P2000 support
[    0.791345] printk: console [netcon0] enabled
[    0.792018] netconsole: network logging started

The notable difference is that the Intel network driver doesn't appear if the nvidia card is installed. That's weird --- why would one piece of hardware block a driver from another piece of hardware? The Intel network driver is compiled into the kernel.

jyoung · Post by **jyoung** » Mon Jul 26, 2021 4:36 pm

And here is the same when booted off a live USB

Code: Select all

[    0.763180] audit: initializing netlink subsys (disabled)
[    1.062115] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    4.067604] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[    4.069933] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
[    4.071858] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    4.083554] VMware vmxnet3 virtual NIC driver - version 1.4.6.0-k-NAPI

Jaglover · Post by **Jaglover** » Mon Jul 26, 2021 4:47 pm

It does not appear in lspci, looks like it is disabled in hardware.

jyoung · Post by **jyoung** » Mon Jul 26, 2021 5:12 pm

I'm not totally sure what you mean. I don't think that some aspect of the physical device is turned off by the presence of the nvidia card, since it works when we boot off the live USB. Here's the lscpi from the live USB:

Code: Select all

00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 05)
00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev 04)
00:14.0 USB controller: Intel Corporation Device a2af
00:14.2 Signal processing controller: Intel Corporation Device a2b1
00:16.0 Communication controller: Intel Corporation Device a2ba
00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode]
00:1c.0 PCI bridge: Intel Corporation Device a294 (rev f0)
00:1c.6 PCI bridge: Intel Corporation Device a296 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Device a2c8
00:1f.2 Memory controller: Intel Corporation Device a2a1
00:1f.3 Audio device: Intel Corporation Device a2f0
00:1f.4 SMBus: Intel Corporation Device a2a3
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1d01 (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 0fb8 (rev a1)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)

Post by **NeddySeagoon** » Mon Jul 26, 2021 6:00 pm

jyoung,

Are you running Gentoo in a Virtual Machine?

Nobody has any real hardware that needs

Code: Select all

[    4.069933] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de

any more.
Then there is

Code: Select all

[    4.083554] VMware vmxnet3 virtual NIC driver - version 1.4.6.0-k-NAPI

They are guest install drivers.

Jaglover · Post by **Jaglover** » Mon Jul 26, 2021 7:49 pm

Whoops, I was looking for an Intel NIC, mislead by IGB driver loading. Now I see there is no Intel NIC in any of your lspci outputs.

jyoung · Post by **jyoung** » Mon Jul 26, 2021 7:50 pm

This live USB is the standard gentoo live image. I believe it's the DVD image, but I created it from an image several years ago. I certainly didn't intend to set it up as a virtual machine.

Jaglover · Post by **Jaglover** » Mon Jul 26, 2021 7:52 pm

OK, so it is Realtek NIC which is not working? Perhaps it is just renamed to something else, courtesy of persistent naming?

Code: Select all

ifconfig -a

jyoung · Post by **jyoung** » Mon Jul 26, 2021 7:59 pm

If it would be useful, I could download the most recent minimal CD image and boot off that.

Jaglover · Post by **Jaglover** » Mon Jul 26, 2021 8:29 pm

OK, more slowly now.

1. Is it Realtek NIC which was working before and is no longer working with nVidia installed?
2. Did the name of NIC change - output of 'ifconfig -a' or 'ip a' ?

jyoung · Post by **jyoung** » Tue Jul 27, 2021 2:07 am

1. Indeed, it's the Realtek device which is inoperative with the nvidia graphics card installed.
2. This afternoon I re-installed the nvidia card to check, and the network card is assigned the same name with and without the nvidia card in place.

In both cases, the network card is assign the name enp2s0. Here's the output of ifconfig -a with the nvidia card installed

Code: Select all

enp2s0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether d8:9e:f3:47:4b:1a  txqueuelen 1000  (Ethernet)
        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

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2  bytes 140 (140.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 140 (140.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

And without the nvidia card

Code: Select all

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.179  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2601:19b:4800:6df:94f2:bd3b:286a:a541  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::2125:e1e6:ff67:1eff  prefixlen 64  scopeid 0x20<link>
        inet6 2601:19b:4800:6df::a5b3  prefixlen 128  scopeid 0x0<global>
        ether d8:9e:f3:47:4b:1a  txqueuelen 1000  (Ethernet)
        RX packets 148932  bytes 186827649 (178.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 103266  bytes 15514277 (14.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 2  bytes 140 (140.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 140 (140.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

And when botted off the live USB (where both work):

Code: Select all

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.182  netmask 255.255.255.0  broadcast 10.0.0.255
        ether d8:9e:f3:47:4b:1a  txqueuelen 1000  (Ethernet)
        RX packets 18  bytes 2490 (2.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 2741 (2.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 28  bytes 1528 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 1528 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Although the device name is the same, there are some differences in the supplementary information. Can any of you folks see clues there?

Interestingly, when it's booted off the live USB the device sit0 doesn't appear. My understanding is that that's the interface between IPv4 and IPv6. I wonder why it's missing from the live USB, and if this is related.

Post by **NeddySeagoon** » Tue Jul 27, 2021 10:02 am

jyoung,

The name changed

And without the nvidia card ... enp1s0
With the nvidia card installed ... enp2s0

jyoung · Post by **jyoung** » Tue Jul 27, 2021 2:27 pm

NeddySeagoon, thanks for catching that!

I'm curious, why would the presence of a graphics device cause a network device's name to change?

Post by Hu » Tue Jul 27, 2021 3:27 pm

You're using predictable network device names, so they are predictably renamed based on the PCI slot in which the device is found. Apparently removing the graphics card changes the PCI slot in which the network device is connected, logically even if not physically.

Spanik · Post by **Spanik** » Tue Jul 27, 2021 6:37 pm

Hu wrote:You're using predictable network device names, so they are predictably renamed based on the PCI slot in which the device is found. Apparently removing the graphics card changes the PCI slot in which the network device is connected, logically even if not physically.

So they are not predictable at all.

This whole idea of those "predicatable" names is not delivering. It is very often that the names from the live-dvd are not what they will be once you have a running install. It is even worse with the /dev/sdx names. Luckily we have UUID to fall back on there because this /dev/sdx has never worked for me for getting the names in Grub right to get it booting after a clean install.

Post by Hu » Tue Jul 27, 2021 6:50 pm

The names are predictable. It's right there in the systemd name for the feature: https://www.freedesktop.org/wiki/Softwa ... faceNames/ ; given the address of a device, you can precisely predict which name it will get.

/dev/sdX names are a bit less stable, and depend on whether your drives enumerate in the same order every time.

jyoung · Post by **jyoung** » Tue Jul 27, 2021 7:05 pm

Okay, it looks like one simple solution would be to add both device names to the default run level (I use openrc), and just let the missing device fail. Hardly elegant, but it would probably work.

I'd actually love to learn more about the predictabitlity of the device names. The article links makes an interesting statment "... they stay fixed even if hardware is added or removed ..." which seems to contradict what we're seeing here. When they say "hardware" are they talking about the card (which I would have assumed had it not been for the present counter example), or do they mean something else?

Post by Hu » Tue Jul 27, 2021 7:15 pm

I believe they did not anticipate the existence of a system where your address changes in reaction to the absence of another device. Personally, I disabled the predictable names long ago, because they add no value on a single NIC system, and I like being able to spell my device's name quickly. enp0s3 doesn't roll off the tongue or my fingers nearly as readily as eth0.

jyoung · Post by **jyoung** » Tue Jul 27, 2021 9:06 pm

That might be a better choice for me as well. I like the idea of predictable names if they're absolutely predictable, but this would seem to be a significant loophole in the mechanism which makes them just as complicated as the generic names (more so, actually, in this case).

Jaglover · Post by **Jaglover** » Tue Jul 27, 2021 9:23 pm

I see my sarcasm was hopelessly lost ...

Post by **NeddySeagoon** » Tue Jul 27, 2021 9:29 pm

jyoung,

The 'predicable' device naming only swapped one set of corner cases for another.
The simplest thing is to turn the feature off. As Hu says, that works as long as you only have a single interface.

Next, is to write a udev rule to name the interface(s) based on their MAC address(es)
Do not choose to use the ethX kernel assigned names.
lanX would be safe.