Вот еще одно простое (r?) Решение: создайте сервис systemd, единственной задачей которого является выгрузка / перезагрузка модуля после цикла приостановки (я назвал его /etc/systemd/system/fix-r8169.service):

[Unit]
Description=Fix RTL-8169 Driver on resume from suspend
After=suspend.target

[Service]
User=root
Type=oneshot
ExecStartPre=/sbin/modprobe -r r8169
ExecStart=/sbin/modprobe r8169
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target

Тогда просто выполните systemctl enable fix-r8169.service, и вы должны быть установлены! Systemd теперь автоматически выгружает и перезагружает ваш модуль после выхода из режима ожидания.

Ура!

Это случилось со мной тоже.

Выгрузка / перезагрузка сетевых модулей ядра / драйверов работает.

Мой r8169, поэтому (как root): (Я набрал вручную, поэтому была задержка)

sudo modprobe -r r8169
sudo modprobe -i r8169

Я также удалил mii во время первой попытки. Не обязательно, хотя.

У меня была такая же проблема, и я нашел это решение.

1. бежать: sudo lshw -C network
   найти модуль ядра вашей сетевой карты

   В *-сети, описание: интерфейс Ethernet, в поле конфигурации найдено
   driver=sky2 для меня. sky2 - модуль ядра сети Ethernet для моего ноутбука.
   

2. Я создаю файл sky2.sh в: /lib/systemd/system-sleep/ папка с

   #!/bin/bash 
   modprobe -r sky2 # unload sky2 kernel module 
   modprobe -i sky2 # reload sky2 kernel module 
   

   и измените разрешения с помощью:

   sudo chmod a+x sky2.sh
   

После этого проблема решена.

Он обнаруживает соединение Ethernet?

затем

открыть NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Комментарий (Добавить #) dns=dnsmasq

[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq

[ifupdown]
managed=true

Перезагрузите сетевой менеджер

sudo service network-manager restart

Я решил эту проблему на своем Ubuntu 18.04 Bionic, обновив ядро ​​с 4.15 до 4.20 (самое позднее 16.01.2019), используя UKUU

установить последнее ядро ​​установить Ubuntu Kernel Update Utility

sudo add-apt-repository ppa:teejee2008/ppa

sudo apt-get install ukuu

отключите контроль доступа с помощью следующей команды:

sudo xhost +

затем установить с помощью уку

sudo ukuu

sudo ukuu --install-latest

и перезагрузка

sudo reboot

Нажмите Ctrl+Alt+T, чтобы перейти к терминалу и введите:

sudo apt-get purge tlp

или же

редактировать /etc/default/tlp и изменить:

WOL_DISABLE = NO

в

WOL_DISABLE = YES

У меня та же проблема (driver=r8169), Ethernet не работает после возобновления из режима ожидания.

Отлично работает с ядром 4.13.0-31. Другими словами, Ethernet продолжает работать после выхода из режима ожидания.

Но с ядром 4.15.0-32 Ethernet не работает после выхода из режима ожидания. Я пробовал исправить

modprobe -r r8169
modprobe -i r8169

но это не имеет никакого эффекта.

Я сообщил об этом на https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

У меня была та же самая проблема, но решения здесь не работали для меня. Я провел дни, просматривая несколько форумов на эту тему, и попробовал почти все. Упоминаются два альтернативных решения: обновить ядро ​​или установить предыдущий драйвер модуля. Я выбрал последнее и установил драйвер r8168. Первоначально это также не удалось. Тем не менее, я обнаружил кое-что, что работает и адаптировал его к решению от Пауло.

Я использую (K) Ubuntu 18.04 с ядром 4.15.0-24.

Вывод из сети lshw -C включает это...

description: Ethernet interface
   product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   vendor: Realtek Semiconductor Co., Ltd.
   physical id: 0
   bus info: pci@0000:05:00.0
   logical name: enp5s0
   version: 0c
   serial: 80:fa:5b:49:69:b3
   size: 1Gbit/s
   capacity: 1Gbit/s
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=r8168 driverversion=8.045.08-NAPI duplex=full ip=192.168.10.213 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
   resources: irq:133 ioport:e000(size=256) memory:df000000-df000fff memory:d0000000-d0003fff

Я установил пакет r8168-dkms, однако этого было недостаточно. Требовались еще два шага.

Шаг 1) Отредактируйте файл /etc/modprobe.d/r8168-dkms.conf и включите строку (т.е. удалите комментарий) в черный список r8169

Шаг 2) На основе решения от Paulo я создал следующий скрипт / lib / systemd / system-sleep / r8168-refresh

 #! / Bin/ Баш

PROGNAME=$(базовое имя "$0")
состояние =$1
Действие =$2

журнал функций {
    logger -i -t "$PROGNAME" "$*"
}

журнал "Запуск $ action $ state"

if [[$ state == post]]; затем
     войти "ifconfig down enp5s0"
     ifconfig enp5s0 down
     журнал "ifconfig up enp5s0"
     ifconfig enp5s0 192.168.10.213
фи 

Этот код, конечно, специфичен для моей машины (имя устройства и IP-адрес). Конечно, это можно улучшить, но на данный момент это отвечает моим потребностям.

Это будет работать с NetworkManager.

У меня недостаточно репутации, чтобы комментировать или оценивать принятый ответ (который сейчас устарел)

Если вы бежите lsmod | grep r8169 и это показывает, что у вас загружен модуль ядра r8169, а ваше ядро ​​старше 4.15.0-24-общего, тогда вы, скорее всего, затронуты ошибкой, указанной в принятом ответе https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772

Кстати, я испытал эту ошибку и для меня lspci | grep 'Gigabit Ethernet' шоуRTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

Эта ошибка была исправлена.

Если ваше ядро ​​старше 4.15.0-24-generic, просто запустите

apt-get update
apt-get upgrade
apt-get dist-upgrade
reboot

Для Dell XPS 7590 это та же команда, но другой адаптер:

sudo modprobe -r r8152
sudo modprobe -i r8152

Я обозначаю, что несколько сценариев Fix файл (модифицированных для моего адаптера Ethernet) на /lib/systemd/system-sleep/ каждый работает!

Тем не менее, если кабельное модемное устройство выключено после приостановки, и оно возвращается после включения системы возобновления, система на основе Ubuntu не может повторно подключиться к Интернету, несмотря на то, что значок сети (в области уведомлений) показывает, что соединение включено.

Чтобы исправить это снова, я должен нажать на значок сети "Ethernet соединение. Таким образом, он успешно обновляет соединение. Икс-

Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] 
    Subsystem: D-Link System Inc DFE-520TX Fast Ethernet PCI Adapter 
    Kernel driver in use: via-rhine
    Kernel modules: via_rhine

PS Похоже, что некоторые CLI vpn перестают работать после возвращения из Suspension.

Первое, что нужно проверить: перезапустите сетевой менеджер / сервис:

перезапуск сетевого менеджера службы sudo

Если это не работает, проверьте другие ответы в этом посте

Были те же проблемы с моим Dell Inspiron 15: нет проводной сети после перезагрузки или приостановки.

Я, кажется, исправил это, изменив настройку в BIOS:

Дополнительно -> Технология Intel (R) Smart Connect -> Отключено

(по умолчанию включено)

Как побочный эффект, пункт меню исчез, чтобы появиться снова после сброса всех настроек к значениям по умолчанию.

Это также случилось со мной с материнской платой Gigabyte-B250M-DS3H после обновления с Ubuntu 16.04 до 18.04 28 июля 2018 года. Ядро имеет стандартную версию 4.15.0-29.

Результат sudo lshw -C network показал RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller, в то время как показал, что драйвером является r8169.

В итоге работала установка драйвера для контроллера Ethernet (большой сюрприз):

sudo apt install r8168-dkms

а затем перезагрузите компьютер (спасибо andypotter). Я не должен был занести в черный список r8169, но мне все еще нужно было создать скрипт в /lib/systemd/system-sleep/ что я звонил r8168-refresh-after-suspend(совет а-ля Паулу), который удалил бы и снова вставил r8168:

#!/bin/bash

# $1 is the state (pre or post)
# $2 is the action (suspend)

case $1/$2 in
pre/suspend)
  modprobe -r r8168
;;
post/suspend)
  modprobe -i r8168
;;
esac

и, конечно, сделать его исполняемым с помощью:

sudo chmod +x /lib/systemd/system-sleep/r8168-refresh-after-suspend

Это работает как шарм. Таким образом, это все еще проблема в ядре 4.15.0-29, но исправление лейкопластыря все еще работает.

Я нашел новое решение для Ubuntu 20.04 LTS на MBP с использованием подключения Thunderbolt2 к Ethernet, где другие ответы работали не очень хорошо.

Я пробовал команды:

      modprobe -r <ethernet-driver>
modprobe -i <ethernet-driver> 

в обоих следующих местах systemd, как указано в предыдущих ответах, но это все еще не работало.

      /lib/systemd/system-sleep
/etc/systemd/system/ 

Я обнаружил, что решение состоит в том, чтобы запустить как сетевой менеджер, так и systemd-networkd, используя ens9 (интерфейс Thunderbolt) в /etc/netplan, но, что более важно, отключить сетевой менеджер и отключить Thunderbolt из командной строки перед приостановкой и переходом в спящий режим, а также запустить сетевой менеджер и подключиться. Thunderbolt из командной строки после приостановки и перехода в спящий режим. Сетевой менеджер, казалось, вызывал гибернацию всегда перезагружаться, а молния при подключении приводила к блокировке приостановки и требовала жесткой перезагрузки.

Я добавил второй файл в /etc/netplan к стандартному сетевому менеджеру, чтобы также разрешить использование systemd-networkd, как предлагается в этом посте:Использование Ethernet-адаптера Apple Thunderbolt 2 в Ubuntu 20.04 .

      /etc/netplan/01-network-manager-all.yaml
    
network:
  version: 2
  renderer: NetworkManager


/etc/netplan/99_config.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens9:
      dhcp4: true
      optional: true

После изучения драйвера Ethernet tg3 и Thunderbolt ens9 с помощью следующих команд просмотрите журналы ядра, systemd и т. д.:

      journalctl | grep tg3 | tail -30
journalctl | grep ens9 | tail -30
dmesg --time-format ctime | grep -a tg3 | tail -n 30
journalctl -u systemd-networkd | grep tg3 | tail -30
grep tg3 -a /var/log/syslog | tail -40

и попытка приостановки/гибернации pm_test, где приостановка больше не работала, даже если для pm_test установлено значение [platform], что не очень помогло, и где команды расположены здесь:https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html

      more /sys/power/disk
more /sys/power/state
more /sys/power/pm_test
echo freezer | sudo tee /sys/power/pm_test
echo devices | sudo tee /sys/power/pm_test
echo platform | sudo tee /sys/power/pm_test

Я использовал следующие команды для проверки соединения Ethernet (и Wi-Fi):

      ifconfig 
speedtest-cli 

Я обнаружил, что остановка диспетчера сети, который удалил драйвер Wi-Fi из (ifconfig), позволила перейти в спящий режим без перезагрузки:

pre-1 -> останавливает диспетчер сети перед приостановкой/переходом в спящий режим

      ### pre-1
sudo systemctl stop NetworkManager.service 

post-1 -> запускает сетевой менеджер после приостановки/гибернации

      ### post-1
sudo systemctl start NetworkManager.service

# confirm the status of network manager
systemctl status NetworkManager.service
ifconfig 
speedtest-cli 

где я остановил диспетчер сети перед приостановкой и перед переходом в спящий режим, после чего он отключил Wi-Fi, но Ethernet все еще работал и запустился после приостановки и перехода в спящий режим, после чего Wi-Fi снова включится.

Затем я работал над тем, как отключить Thunderbolt с помощью командной строки, так как я обнаружил, что, когда компьютер был подключен только к Wi-Fi, а кабель Thunderbolt-Ethernet не был физически подключен, я мог приостановить и разбудить компьютер. Я нашел следующие команды после долгих поисков, которые смогли отключить тандерболт, что подтверждается командами Boltctl и ifconfig:

pre-2 -> отключает Thunderbolt перед приостановкой/гибернацией

      ### pre-2  ->  disconnects thunderbolt'   
echo "1" | sudo tee /sys/devices/pci0000:00/0000:00:1c.4/remove > /dev/null  

примечание: вы должны найти местоположение /sys/..... из списка Boltctl и информацию о Boltctl в первой части 'syspath'

post-2 -> подключить молнию, от сканирования шины pci, после приостановки/гибернации

      ### post-2  -> connect thunderbolt, after scanning pci bus
echo "1" | sudo tee /sys/bus/pci/rescan > /dev/null  

# tests connection before and after thunderbolt disconnect and connect
boltctl list # to find the uuid of the device
boltctl info <uuid> to find the 'syspath'
ifconfig 
speedtest-cli 

Это использует местоположение шины pci DDDD:BB:DD.F, указанное в приведенной выше команде, для отключения молнии, где команда для подключения и отключения устройства pci указана в ссылке kernel.org ниже. Я также положил ссылку пример на ссылку суперпользователя ::

https://superuser.com/questions/1046928/thunderbolt-hotplugging-in-ubuntu-linuxhttps://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci

Вышеупомянутая концепция заключается в отключении Thunderbolt от команды sysfs-bus-pci, поскольку у Boltctl еще нет команды для отключения, по крайней мере, в ядре Linux 5.11.

Запустив ### pre-1 и ### pre-2 выше перед запуском systemctl suspend или systemctl hibernate, а затем запустив ### post-1 и ### post-2 после приостановки/гибернации, Ethernet теперь работает отлично. после приостановки/гибернации и приостановки/гибернации каждый раз работает как положено.

Резюме:

Перед приостановкой/переходом в спящий режим

      ### pre-1
sudo systemctl stop NetworkManager.service 
### pre-2  ->  disconnects thunderbolt'   
echo "1" | sudo tee /sys/devices/pci0000:00/0000:00:1c.4/remove > /dev/null  

После приостановки/гибернации

      ### post-1
sudo systemctl start NetworkManager.service
### post-2  -> connect thunderbolt, after scanning pci bus
echo "1" | sudo tee /sys/bus/pci/rescan > /dev/null  

Раньше я получал ошибки для драйвера Ethernet, что он не мог изменить состояние питания.

Это были предыдущие ошибки до использования решения с pre-1, pre-2 и post-1 и post-2, которые я только что указал, и 2 решения с использованием modprobe в /lib/systemd/system-sleep и /etc/systemd /system/ выше другими ответами не работали ниже для меня, хотя в приведенном ниже примере я прокомментировал разделы modprobe после их попытки.

      Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: can't change power state from D3hot to D0 (config space inaccessible)
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: phy probe failed, err -19
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: invalid large VPD tag 7f at offset 0
Nov 06 16:23:25 mbp-ubu kernel: tg3 0000:3c:00.0: Problem fetching invariants of chip, aborting
Nov 06 18:04:29 mbp-ubu driver_tg3-refresh[7811]: Running suspend pre
Nov 06 18:04:29 mbp-ubu driver_tg3-refresh[7812]: now logging in pre
Nov 06 18:05:09 mbp-ubu driver_tg3-refresh[7835]: Running suspend post
Nov 06 18:05:09 mbp-ubu driver_tg3-refresh[7840]: now logging in post
Nov 06 18:05:09 mbp-ubu systemd[1]: Starting Fix tg3 ethernet driver on resume from suspend/hibernate...
Nov 06 18:05:09 mbp-ubu systemd[1]: fix-wake-ethernet-tg3.service: Succeeded.
Nov 06 18:05:09 mbp-ubu systemd[1]: Finished Fix tg3 ethernet driver on resume from suspend/hibernate.

Проблема заключается в состоянии питания соединения Ethernet и/или Thunderbolt, которое не может быть изменено или изменено вовремя, а решение по отключению Thunderbolt от команд linux /sys pci выше и удалению сетевого менеджера привело к согласованному решению. для меня, поскольку он удаляет молнию и Ethernet задолго до приостановки и перехода в спящий режим, и вы можете создавать сценарии bash для автоматизации или псевдоним в ~/.bashrc.

Обновление (11.11.2021)

Окончательное решение:

На Macbookpro с Ubuntu 20.04 LTS linux и подключением к Интернету с подключением Thunderbolt2 к
Ethernet, где кабель Thunderbolt-Ethernet вызывает проблемы с приостановкой/спящим режимом:

Перед приостановкой/гибернацией:

• Отключить Thunderbolt
• Остановить диспетчер сети

После приостановки/гибернации:

• Подключить Thunderbolt
• Запустите диспетчер сети

Мне удалось разработать новый сценарий systemd в том же месте, что и исходный выбранный ответ Пауло Марселя Коэльо Арагао, и я подтвердил, что он работает.

В этом случае Thunderbolt отключается, а затем отключается NetworkManager перед приостановкой/переходом в спящий режим, а после приостановки/гибернации подключается Thunderbolt и включается NetworkManager. Это делается для того, чтобы приостановка/гибернация не прерывалась и не завершалась ошибкой из-за проблемы, изменяющей состояние питания Thunderbolt/Ethernet с D0 на D3 или наоборот, что приводит к перезагрузке компьютера или принудительной перезагрузке. Недавно я обнаружил, что если оставить NetworkManager включенным перед приостановкой/спящим режимом, это может привести к перезагрузке спящего режима.

Ниже приведено содержимое , и оно было протестировано на очень хорошую работу, но вы должны изменить расположение интерфейса разъединения pcie для Thunderbolt, как указано ранее в этом ответе выше, с на расположение вашего интерфейса ethernet/thunderbolt, а также добавить .

Детали окончательного решения:

- Добавлять /etc/netplan/99_config.yamlкак указано выше, изменение ens9
- Добавлять /lib/systemd/system-sleep/pre-post_suspend-hibernateниже, модифицируя: /sys/devices/pci0000\:00/0000\:00\:1c.4

/lib/systemd/system-sleep/pre-post_suspend-hibernate

      #!/bin/bash

PROGNAME=$(basename "$0")
state=$1
action=$2

function log {
     logger -i -t "$PROGNAME" "$*"
}

log "Running $action $state"

if [[ $state == pre ]]; then
    log "following is ifconfig before attempt to disconnect thunderbolt:" && \
    ifconfig 2>&1 | logger
    log "disconnecting thunderbolt" && \
    echo "1" | /usr/bin/tee /sys/devices/pci0000\:00/0000\:00\:1c.4/remove > /dev/null
    log "following is ifconfig after attempt to disconnect thunderbolt:" && \
    ifconfig 2>&1 | logger
    log "stopping NetworkManager" && \
    systemctl stop NetworkManager.service 
    log "following is ifconfig after stopped NetworkManager:"
    ifconfig 2>&1 | logger
fi

if [[ $state == post ]]; then
    log "following is ifconfig before attempt to connect thunderbolt:" && \
    ifconfig 2>&1 | logger
    log "re-connecting thunderbolt" && \
    echo "1" | /usr/bin/tee /sys/bus/pci/rescan > /dev/null 
    log "following is ifconfig after attempt to connect thunderbolt:" && \
    sleep 1 && log "sleep 1" && \
    ifconfig 2>&1 | logger
    log "starting NetworkManager" && \
    systemctl start NetworkManager.service 
    log "following is ifconfig after started NetworkManager:" && \
    sleep 1 && log "sleep 1" && \
    ifconfig 2>&1 | logger
fi

Вы можете проверить это, просмотрев журналы в /var/log/syslogили же journalctlгде выбран «root», так как приведенный выше скрипт в systemd вызывается из «root». «pre-post» — это часть названия скрипта выше. Вы можете добавить «grep -e tg3 -e ens9», где tg3 — это имя драйвера Ethernet, а ens9 — имя интерфейса Thunderbolt для этого компьютера. Все это можно протестировать, установив для /sys/power/pm_test значение «freezer», а затем вернув /sys/power/pm_test значение «none», когда вы закончите, чтобы выйти из тестового режима, где «freezer» отлично подходит для быстрая отладка и тестирование, так как это только замораживает процессы.

      grep -e pre-post -e root /var/log/syslog | tail -70
journalctl | grep -e sudo | tail -35
journalctl | grep -e ens9 -e tg3 -e pre-post -e sudo | tail -120
lll /sys/devices/pci0000:00/0000:00:1c.4
more /sys/power/disk; more /sys/power/state; more /sys/power/pm_test
echo freezer | sudo tee /sys/power/pm_test
echo none  | sudo tee /sys/power/pm_test
systemctl suspend
systemctl hibernate

journalctl более полный, чем /var/log/syslog, так как в нем есть все журналы, и вы можете найти больше о journalctl по адресу:https://www.digitalocean.com/community/tutorials/how-to-use-journalctl . -to-view-and-manipulation-systemd-logs

Обновление от 27.11.2021:

• Теперь я исправил спящий режим, чтобы он всегда возобновлялся и не перезагружался после пробуждения, используя добавление установки uswsusp, которая использует s2disk для копирования образа в раздел или файл подкачки и проверяет его, обеспечивая пробуждение из hibernate всегда восстанавливает образ. Необходимо добавить сценарий переопределения в systemd. Эта ссылка и другие ссылки охватывают эту операцию.
  https://unix.stackexchange.com/questions/320675/how-to-use-uswsusp-for-standby-hibernation-with-systemd-debian

Следующее создаст новый файл ovveride в месте, зависящем от вашей машины, но в данном случае в:/etc/systemd/system/systemd-hibernate.service.d/override.conf

Установите это исправление в режим гибернации с помощью следующих команд:

      sudo apt install uswsusp
sudo systemctl edit systemd-hibernate.service
[Service]
ExecStart=
ExecStartPre=-/bin/run-parts -v -a pre /lib/systemd/system-sleep
ExecStart=/usr/sbin/s2disk
ExecStartPost=-/bin/run-parts -v --reverse -a post /lib/systemd/system-sleep

Следующая команда должна показать вам файл systemd-hibernate.service и файл переопределения:

      sudo systemctl cat systemd-hibernate.service

Обновите systemd или перезагрузитесь:

      $ sudo systemctl daemon-reload

Теперь беги

      $ sudo systemctl hibernate