# [SOLVED] gpu causes loss of USB and network

## jyoung

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!Last edited by jyoung on Wed Aug 04, 2021 2:21 am; edited 1 time in total

----------

## Ralphred

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

```
lspci -kv
```

please.

----------

## jyoung

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

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.

```

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

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 

```
dmesg  | grep net
```

 on the system without the nvidia card I get

```

[    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 

```

[    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

And here is the same when booted off a live USB

```
[    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

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

----------

## jyoung

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:

```
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)

```

----------

## NeddySeagoon

jyoung,

Are you running Gentoo in a Virtual Machine? 

Nobody has any real hardware that needs 

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

any more.

Then there is 

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

They are guest install drivers.

----------

## Jaglover

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

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

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

```
ifconfig -a
```

----------

## jyoung

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

----------

## Jaglover

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

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

```
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

```
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):

```
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.

----------

## NeddySeagoon

jyoung,

The name changed

And without the nvidia card ... enp1s0

With the nvidia card installed ... enp2s0

----------

## jyoung

NeddySeagoon, thanks for catching that!

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

----------

## Hu

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

 *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.

----------

## Hu

The names are predictable.  It's right there in the systemd name for the feature: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ ; 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

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?

----------

## Hu

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

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

I see my sarcasm was hopelessly lost ...

----------

## NeddySeagoon

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.

----------

## Leonardo.b

ip from iproute2 can rename network interfaces as well.

https://paulgorman.org/technical/linux-iproute2-cheatsheet.html#Rename%20an%20interface

----------

## jyoung

Okay, some really good news: When I enabled enp2s0, the system was able to the network without issue. I did have to disable enp1s0, since a few services complained at boot that they couldn't find a connection after enp1s0 failed. I would be happy to mark this thread as 'SOLVED', although I do have a few more questions.

NeddySeagoon, what are your thoughts on the ethX names? Names based on MAC addresses would certainly be unique.

Leonardo.b, I've seen other distros use this tool exclusively instead of ifconfig, and I note that the documentation says that iconfig is supported only for backward compatibility. Perhaps it's time to migrate? My system is not complex and I'm not doing anything really intense, but it's worth avoiding getting marooned in legacy software. On the other hand, if ifconfig is likely to stay around for a while, then it might be worth sticking with a simpler tool for the sake of simplicity.

----------

