No Ethernet Network Connection after Resume; very recent problem

[kdemeoz@GA-Z97-HD3-Tower ~]$ sudo echo "blacklist r8168" | sudo tee -a /etc/modprobe.d/blacklist.conf
blacklist r8168
[kdemeoz@GA-Z97-HD3-Tower ~]$
 [kdemeoz@GA-Z97-HD3-Tower ~]$ cd /etc/modprobe.d
[kdemeoz@GA-Z97-HD3-Tower modprobe.d]$ ls
[kdemeoz@GA-Z97-HD3-Tower modprobe.d]$ cat blacklist.conf 
blacklist r8168
[kdemeoz@GA-Z97-HD3-Tower modprobe.d]$

I'm sorry for my ignorance, but i'm now about to reboot, without an installed active NM driver... will the r8169 be detected & activated during this reboot... or am i about to reboot into a no-network nightmare?

The driver should be automatically detected and loaded upon reboot.

If it is not enter these commands in the new kernel.

sudo modprobe r8169

sudo depmod -a
1 Like

Ta muchly. About to reboot now, into 4.17 from current 4.14. Copied your post into a saved text file, as insurance against possible no-network [coz then obviously browser won't show me this page]. Post-reboot, before doing anything else [apart from verifying i'm online], i'll Suspend then Resume, to see what happens. See you soon fingers crossed.

1 Like

Hello again. I am back online [duh], in 4.17.9, & have done these things whilst "away":

  1. Now there is no evidence of ANY Ethernet driver installed & active, from these two commands [also from the Manjaro Settings Manager GUI]:
[kdemeoz@GA-Z97-HD3-Tower ~]$ mhwd  -li
> Installed PCI configs:
                  NAME               VERSION          FREEDRIVER           TYPE
           video-intel            2017.03.24                true            PCI

Warning: No installed USB configs!
[kdemeoz@GA-Z97-HD3-Tower ~]$ mhwd -la
> All PCI configs:
                  NAME               VERSION          FREEDRIVER           TYPE
   network-broadcom-wl            2015.12.13                true            PCI
     network-rt3562sta            2013.12.07                true            PCI
         network-r8168            2016.04.20                true            PCI
video-hybrid-intel-nvidia-340xx-bumblebee            2018.05.04               false            PCI
           video-geode            2017.03.12                true            PCI
          video-vmware            2017.03.12                true            PCI
             video-apm            2017.03.12                true            PCI
      video-virtualbox            2017.03.12                true            PCI
         video-s3virge            2017.03.12                true            PCI
          video-cirrus            2017.03.12                true            PCI
             video-ast            2017.03.12                true            PCI
       video-rendition            2017.03.12                true            PCI
          video-savage            2017.03.12                true            PCI
          video-mach64            2017.03.12                true            PCI
             video-ark            2017.03.12                true            PCI
        video-catalyst            2017.03.12               false            PCI
           video-chips            2017.03.12                true            PCI
             video-mga            2017.03.12                true            PCI
         video-trident            2017.03.12                true            PCI
            video-tdfx            2017.03.12                true            PCI
    video-nvidia-304xx            2018.05.04               false            PCI
video-hybrid-intel-nvidia-390xx-bumblebee            2018.05.04               false            PCI
    video-nvidia-340xx            2018.05.04               false            PCI
           video-linux            2018.05.04                true            PCI
          video-sisusb            2017.03.12                true            PCI
    video-intel-gma500            2017.03.12                true            PCI
      video-openchrome            2017.03.12                true            PCI
   video-siliconmotion            2017.03.12                true            PCI
            video-i740            2017.03.12                true            PCI
    video-nvidia-390xx            2018.05.04               false            PCI
          video-nvidia            2018.05.04               false            PCI
              video-s3            2017.03.12                true            PCI
       video-sisimedia            2017.03.12                true            PCI
            video-vesa            2017.03.12                true            PCI
        video-neomagic            2017.03.12                true            PCI
          video-voodoo            2017.03.12                true            PCI
           video-tseng            2017.03.12                true            PCI
           video-glint            2017.03.12                true            PCI
            video-r128            2017.03.12                true            PCI
video-hybrid-intel-nvidia-bumblebee            2018.05.04               false            PCI
             video-sis            2017.03.12                true            PCI
            video-i128            2017.03.12                true            PCI

Warning: No USB configs found!
[kdemeoz@GA-Z97-HD3-Tower ~]$

So that's pretty weird. Conversely when i do this...

  1. new/updated driver is evident:
[kdemeoz@GA-Z97-HD3-Tower ~]$ mhwd -lh -d

11: PCI 200.0: 0200 Ethernet controller
  SysFS ID: /devices/pci0000:00/0000:00:1c.2/0000:02:00.0
  SysFS BusID: 0000:02:00.0
  Hardware Class: network
  Model: "Gigabyte Onboard Ethernet"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
  SubVendor: pci 0x1458 "Gigabyte Technology Co., Ltd"
  SubDevice: pci 0xe000 "Onboard Ethernet"
  Revision: 0x0c
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: enp2s0
  I/O Ports: 0xe000-0xe0ff (rw)
  Memory Range: 0xf7c00000-0xf7c00fff (rw,non-prefetchable)
  Memory Range: 0xf0000000-0xf0003fff (ro,non-prefetchable)
  IRQ: 18 (8 events)
  HW Address: fc:aa:14:5c:74:10
  Permanent HW Address: fc:aa:14:5c:74:10
  Link detected: yes
  Module Alias: "pci:v000010ECd00008168sv00001458sd0000E000bc02sc00i00"
  Driver Info #0:
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
  Attached to: #22 (PCI bridge)
  1. Rebooted into 4.17, network available [despite the above oddities], Suspended, Resumed... Nwtwork available again. :grinning:

  2. Rebooted into 4.16, network available, Suspended, Resumed... Network UNavailable, running your commands did not help.

  3. Rebooted into 4.14, network available, Suspended, Resumed... Network available again.

  4. Rebooted into 4.17, network available, Suspended, Resumed... Network available again.

  5. Deleted kernel 4.16.

Sooooooooo, Ethernet driver r8169 made a BIG improvement [albeit not 100% successful, given 4.16 remained broken post-Resume]. Hence, 8 days ago, by implication, driver r8168 "broke" ... how is that possible?

Thank you so much, bigtime; it's clever & generous of you.

I think i need to just accept that i will never know WHY things went bonkers 8 days ago.

It's simply a kernel incompatibility issue. These happen all the time with network drivers. C'est la vie, life in the big city, and all that (as they say).

This is of no consequence, don't worry about that issue.

The rest will get ironed out as new kernel updates come along. Glad it improved things for you.

1 Like

Hey Oz.

Sorry so soon after your victory to possibly rain on your parade. I just noticed you had s Gigabyte MOBO with your r8168. That is a combination that has caused network problems on many boards. They are also known for poor USB support on some boards. Both myself and mandog have one of those problematic boards. I'm amazed how often I see problems related to the Gigabyte mobos on the forums. I'm surprised I never noticed this on your posts before. That's usually a red flag to me as soon as I see GB and r8168. They also have USB driver issues in Linux (mine does). If you don't have USB initialization errors at boot your USB driver are probably not affected.

You might want to check for a bios update for your board. Gigabytye doesn't seem to care about fixing this issue in Linux so there probably isn't one. Anyways, here's some info.

With all the problems you've had I just thought I'd mention the iommu settings option for your mobo. Oh , I just remembered you use virtualization. You cant use iommu=soft if you run VM's you need to use the pt setting for virtualization.

Oops, the pt setting won't work either as you're on an Intel CPU. Oh well good info for other Gigabyte owners to know. Sorry for wasting your time.

I'd still check into the BIOS update if I were you though.

Haha, talk about ups & downs as i read this post. Thanks anyway for thinking more about my help, i appreciate it. Re USBs, no particular problems here so far afaik... but given that my Ethernet driver spontaneously ate itself 8 days ago, who knows, maybe late next week my USB drivers will decide to immolate. Ha.

Re potential BIOS update, that is something i definitely have considered evaluating a few times since 2015, but each time i looked into HOW to do it my head exploded. BIOS updates were simple to do back when i still used Win7, but in Linux it seems that i have to cobble up some USB stick running some special old Windows version & boot from that then somehow load the new BIOS to flash from that stick. Clearly i don't yet understand it, & i need to re-research it, but tbh i lazily just kept deferring this until some undefined future time when i could no longer avoid it. I'm still not sure if that time has arrived yet... :roll_eyes:

Maybe try using a copy of Hiren's boot CD to load and run your bios update.

Will research that tomorrow -- thanks.

Depending on what part of Canada, your local time is now 03:30, 05:30 or 06:30. Afaik you've been active on the forum since my yesterday. You're really amazing... i used to believe i run on much less sleep than "normal" people, but i am a total amateur compared to you! :rofl:

It will catch up to me one of these days, but I'm still outrunning the Devil so far. Knock on wood.

I forgot there is an intel setting:

edit /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt"

sudo update-grub


Test it out if you'd like to see if the wee beasitie living in your tower can be ejected.


MHWD always mis-identifies the same ethernet hardware driver needed on my Lappy. Same as yours. Hence I either have to remove it or use the M-A installer.

I apologize for not recognizing your difficulties. It's just "one of those things" I've grown accustomed to with this machine over the past 4 years.


Oh no, please no... NO apology of any kind is needed here.

Your info, combined with that from @tbg in this thread, re MHWD & r8168/r8169, is highly useful & interesting. As my posts yesterday showed, changing from r8168 to r8169 fully restored "normal" Suspend-Resume network functionality for kernel 4.17 [& this morning's Resume from overnight sleep also worked correctly - phew!], so ostensibly all is fabulous again now.

I know therefore that it's foolish of me to look gift horses in the mouth, but it's ingrained in me to always ask myself "WHY?", & strive my best to answer it. Hence in this case, i certainly am interested to learn from you of this apparent difficulty of MHWD to identify & install the correct driver... but here's the thing. I have bored you all enough already, but here's one more [expanded] repeat of it... my Manjaro installation occurred late last year, ie, that was when all HW detection & driver selection occurred, ie, logically that was when r8168 was installed & activated. All the rest of 2017, & all of 2018 until 9 days ago, this Tower was running r8168, & was happily Suspend-Resuming with normal functionality. Whether or not r8168 was "rightly" or "wrongly" installed by MHWD last year is IMO a purely secondary issue... if it was a totally hopeless trainwreck of a useless driver incompatible with my HW then i should have been having problems directly after installation last year... or otherwise, immediately after whatever kernel version upgrade became incompatible with this driver. BUT none of that explains why it "broke" 9 days ago, when there had been NO kernel or relevant SW update immediately beforehand. THAT's the single aspect of this mystery that continues to fry my brain... it is simply illogical IMO, yet the history is what it is, regardless of "logic". I just hate such mysteries.

Thank you for this. I know nothing about "iommu", never heard of it before, so today or tomorrow will research it & if i can grasp it & see a possible benefit to me then i'll try applying your grub edit. :confused:

Electricity is illogical to most people since they can't see it, but it follows all the truths associated with it. Computers are the same. And my computer's logic is less flawed than my own. :wink:

Yeah, but seeing ain't believing. I can see trump, but can't believe him, & certainly he is a Logic [& Truth]-Free Zone. Oops, i fear i just transgressed a forum rule...


Still know little about it, but have DDG'd it & read many pages, including and

Given it was linked in an earlier post in this current thread, i also read, which was a horror-show!

However, none of the pages i read seem applicable to my scenario, hence i struggle to comprehend exactly what perceived "problem" of mine now this "solution" is intended to resolve...? Some of those pages mentioned USB problems... but i do not have any such problems. Other pages mentioned that IOMMU can help with either allowing, or improving, Virtual Machine performance... but i do not have any such problems. My 1st pasted link above mentions boot problems, & memory problems... but i do not have any such problems. My 2nd pasted link above mentions sound problems & again memory problems... but i do not have any such problems.

Puzzled but moderately undaunted, i dug a bit deeper. I opened my MoB User Guide in Okular, did an initial dummy search with a simple keyword to confirm the search function works [yes], then searched for "IOMMU" ... zero hits. Hmmm. Next i thought i'd see if any nasty IOMMU messages have been accruing in the journal, so...

[kdemeoz@GA-Z97-HD3-Tower ~]$ dmesg --level=err,warn -T | grep IOMMU
[kdemeoz@GA-Z97-HD3-Tower ~]$

[kdemeoz@GA-Z97-HD3-Tower ~]$ dmesg | grep IOMMU
[kdemeoz@GA-Z97-HD3-Tower ~]$

I absolutely do not want to sound like an ingrate, as i truly value the nice help i get here, but i have to say that at this stage i do not feel inclined [sorry] to proceed @tbg with your clever-looking grub edit:
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt"
...without a clear idea of what specifically is the objective here. When you said:

... & again with no disrespect meant, but atm i don't see evidence of this fabled beastie at all, in as much as my Tower is once again correctly Suspend-Resume networking, now that it uses the newer driver. Unless i'm overlooking something, atm my Tower seems to be all nice & happy once more.

You do not "need" to add these boot options. However, they are not just meant for USB issues, they are also to resolve network issues on Gigabyte MOBO's with the r8168 card. Considering all the issues you've had with your tower I figured it couldn't hurt to try it out.

You are correct you do not"need" to implement these changes. At the same time you did not "need" to change your drivers either. Changing your drivers was not essential, they were working adequately well. However, changing your drivers did result in an improvement in usability.

You would never have known that, if you hadn't tested it out. Just as you do not know if a bios update will improve your computers performance until you implement the update. I'm not twisting your arm to test this out if you don't feel like it. If you are uncomfortable altering your grub load line then please don't do it.

If you do feel like testing it out, simply add those options at the end of the load line. You do not need to do anything you are uncomfortable with. At the same time these options should cause you no problems, and they are easily removed if you find no improvement.

There is actually more risk performing a bios update than from simply altering your grub load line. Only do what you feel comfortable with. Please, do not feel I will be upset with you if you do not feel like implementing my suggestion. I will certainly not be unhappy in the least. It is your computer. I will be the first person to agree the odds of it being a big positive are slight, but at the same time the odds of it resulting in anything negative are even more remote.

I always enjoy reading your posts, all the best.

1 Like

Really? But i am chronically hopelessly undeniably

...and certainly also extraordinarily


You know me I just like ribbing you. It's all in good humor. :smile:

Forum kindly sponsored by