LINUX.ORG.RU

WakeOnLan работает первые 5-10 минут после выключения

 , , , ,


0

1

Приветствую, есть Lenovo ThinkCentre M73 Tiny Desktop. Хочу на нем WOL. При выключении из Linux (Debian 10), разбудить компьютер по WOL могу только в течении 5-10 минут после выключения, после индикатор сети на роутере гаснет, а на Леново раз в 2 секунды Зеленый/Желтый промигивают.

На роутере через некоторое время после выключения видно это:

Sun Mar 28 17:11:51 2021 kern.info kernel: [64344.956848] mtk_soc_eth 1e100000.ethernet eth0: port 3 link up
Sun Mar 28 17:19:17 2021 kern.info kernel: [65031.329817] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down

Понятное дело, параметр WOL в BIOS стоит в состоянии Enable. На Debian также все настроено согласно их вики и немного из вики арча, т.е. в любой момент всегда можно запустить ethtool eno1 | grep Wake и получить:

	Supports Wake-on: pumbg
	Wake-on: pbg
Включал всё через nmcli. Собственно вывод: (за нейм на кириллице, каюсь)
~# nmcli c show Проводное\ соединение\ 1 | grep 802-3-ethernet.wake-on-lan
802-3-ethernet.wake-on-lan:             phy, broadcast, magic
802-3-ethernet.wake-on-lan-password:    --

Что делал, менял сетевой кабель, менял порт на роутере, обновил bios до последней версии, пробовал устанавливать ядро из backports, пробовал подкидывать диск с установленной Ubuntu 20.04, игрался с различными параметрами в bios.

Интересно, что если Леново выключить из BIOS или из Windows такой проблемы нет, линк стабильно держится неограниченное время, также обнаружил, что передергивание питальника на нём также помогает.

В связи с этим могу предположить, что при выключении из bios или из windows, происходит Reset сетевого контроллера и он забывает параметры заданные системой и задействует выставленные в bios(с которыми линк держится). Это подтвердил мой эксперимент когда в Дебиан я отключил WOL. После выключения индикации сети небыло, но после передергивания питания, она появлялась. Думаю это некий баг BIOS.

Собсвенно мучаюсь уже 2-е суток, ушло полтора ящика пива, пытаюсь копать в направлении ресета сетевого контроллера при выключении, но пока безуспешно. Если у кого-то есть мысли по этому поводу, с удовольсвием приму их. И спасибо, что дочитали до конца.

Вот полный dmesg загрузки системы.

Сетевой контроллер: 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)

P.S. другие устройства подключенные к роутеру этой проблемой не страдают и просыпаются всегда нормально.


При выключении из Linux (Debian 10), разбудить компьютер по WOL могу только в течении 5-10 минут после выключения, после индикатор сети на роутере гаснет

Что делал, менял сетевой кабель, менял порт на роутере, обновил bios до последней версии, пробовал устанавливать ядро из backports, пробовал подкидывать диск с установленной Ubuntu 20.04, игрался с различными параметрами в bios.

ожидаемо

если Леново выключить из BIOS или из Windows такой проблемы нет, линк стабильно держится неограниченное время, также обнаружил, что передергивание питальника на нём также помогает.

бинго?

мучаюсь уже 2-е суток, ушло полтора ящика пива, пытаюсь копать в направлении ресета сетевого контроллера при выключении, но пока безуспешно. Если у кого-то есть мысли по этому поводу, с удовольсвием приму их

копать в сторону ACPI – это «извечный порок» многих устройств на которые пользователь ставит линуксы. Рецептов есть некоторое подмножество, но который твой?

за нейм на кириллице, каюсь

переименуй используя латинницу (не поможет, конечно, но перестанешь страдать из-за кириллицы)

сейчас ещё dmesg почитаю…

anonymous
()

первые впечатления

попробовать вместо acpi_osi=Linux acpi_osi=Windows (лучше ориентироваться на ту версию, что у тебя стоит – погуглишь какие возможны варианты)

посмотри dmesg при засыпании и пробуждении Debian (с учетом твоей ситуации по WakeOnLan и без него) может какие моменты всплывут.

anonymous
()
Ответ на: комментарий от zemidius

Разве не ясно? Или ты думаешь, что ядро без твоего указания (я о параметре acpi_osi) представляется BIOS-у как winda?

Легко же проверить при загрузке в своей системе. Загружаешь с параметром, смотришь dmesg. Загружаешь без параметра, смотришь dmesg. Видишь разницу?

anonymous
()
Ответ на: комментарий от anonymous

Разве не ясно? Или ты думаешь, что ядро без твоего указания (я о параметре acpi_osi) представляется BIOS-у как winda?

Нет, не ясно. На прошлом буке явно прописывал acpi_osi=Linux, чтобы работало отключение дискретной видеокарты.

zemidius
()
Ответ на: первые впечатления от anonymous

Попробовал загрузиться с параметром acpi_osi=Windows проверил в dmesg, изменений не заметил. По поводу нюансов, есть один, не уверен что оно, проявляется только при пробуждении из suspend или hibernate в dmesg наблюдается такое:

[  624.811441] pciehp 0000:00:1c.0:pcie004: link training error: status 0x1001
[  624.818168] pciehp 0000:00:1c.0:pcie004: Failed to check link status

Нагуглил решение, мол добавлением опций pciehp.pciehp_force=1 и acpi_osi=Linux, но варнинги эти остались.

Также когда гасишь машину она на все tty пишет некоторую не совсем ясную мне инфу, с упоминанием сетевой карты, инфу эту в логах потом я найти не могу. Поэтому получилось только сфоткать на тапок в момент отправки в гибернацию, за что соррян)

Shiroe
() автор топика
Ответ на: комментарий от zemidius

В моем случае изначально без этих опций Леново плохо себя вела. Добавление их должно было якобы решить проблему описанную выше, но нет.

Shiroe
() автор топика
Ответ на: комментарий от Shiroe

В моем случае изначально без этих опций Леново плохо себя вела.

Когда именно? Обновлялся ли биос после добавления (судя по dmesg он последней версии)? Попробуй убери все опции и проверь работу WOL.

zemidius
()
Ответ на: комментарий от zemidius

На прошлом буке явно прописывал acpi_osi=Linux, чтобы работало отключение дискретной видеокарты.

Ты счастливчик. Обычно BIOS «кладёт» на acpi_osi=Linux и признаёт только Windows.

На прошлом буке

это не считается :) Как нынешнее железо работает без указания acpi_osi или при указании acpi_osi=Linux?

anonymous
()
Ответ на: комментарий от anonymous

это не считается :)

Считается :)

Как нынешнее железо работает без указания acpi_osi

Отлично. Но «ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored»

zemidius
()
Ответ на: комментарий от Shiroe

гугли отталкиваясь от версии windows, которая у тебя работает: варианты бывают разные от acpi_osi=!Linux до acpi_osi="Windows" | acpi_osi="Windows 2018" (я не знаю какой вариант у тебя может сработать)

когда гасишь машину она на все tty пишет некоторую не совсем ясную мне инфу

Блин-н-н! У тебя при входе в гибернацию вотчдог сетевухи фейлится… Репорти о баге разрабам, ищи патчи. Сорри.

anonymous
()
Ответ на: комментарий от zemidius

Проверил, также упал линк через 7 минут.

Shiroe
() автор топика
Ответ на: комментарий от zemidius

ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

это значит «отлично», ну хорошо, пускай. Кстати, откуда BIOS догадался что _OSI(Linux)? Ты же убрал из параметров ядра acpi_osi? Видимо, в твоём BIOS-е уже и ИИ прошили.

anonymous
()
Ответ на: комментарий от zemidius

Смотри наш диалог с самого начала. Я говорил, что без этого параметра и с указанием acpi_osi=Linux поведение одинаковое. Ты какую-то разницу ожидал. Пойдём на второй круг?

anonymous
()
Ответ на: комментарий от anonymous

Я говорил, что без этого параметра и с указанием acpi_osi=Linux поведение одинаковое.

На старом ноутбуке поведение было разное. Так что не всегда.

zemidius
()
Ответ на: комментарий от zemidius

На старом ноутбуке поведение было разное. Так что не всегда.

не всегда, но чаще встречается «мой» вариант. А так «да», я подозреваю, что там вариантов «реакции» даже больше, чем 2.

А у ТС твоя версия подтверждается?

anonymous
()
Ответ на: комментарий от anonymous

но чаще встречается «мой» вариант.

У меня нет достаточной выборки железа, которому надо было acpi_osi прописывать, поэтому спорить не буду.

А так «да», я подозреваю, что там вариантов «реакции» даже больше, чем 2.

Скорее всего, учитывая то, как пишут левой пяткой биосы :)

А у ТС твоя версия подтверждается?

Я не видел dmesg без параметров, поэтому не знаю.

zemidius
()
Ответ на: комментарий от zemidius

Он выше фото выкладывал с бектрейсом – падает у него модуль при вхождении в гибернацию.

anonymous
()
Ответ на: комментарий от anonymous

Моя версия была - «убрать все дописанные параметры и попробовать без них». Больше версий у меня пока не было. Не надо мне приписывать другое :)

zemidius
()
Последнее исправление: zemidius (всего исправлений: 1)
Ответ на: комментарий от zemidius

Ничего я тебе не приписываю. У него там креш перед засыпанием, на фото подробности. Моё кунгфу здесь бесполезно, а кроме тебя и меня есть только ТС в треде.

anonymous
()
Ответ на: комментарий от zemidius

Вот dmesg без параметров. На мой взгляд особо ничего не сменилось.

Shiroe
() автор топика

Ночью натыкал ещё одну особенность, немного позже попробую объяснить.

Shiroe
() автор топика
Ответ на: комментарий от zemidius

Попробовал загрузиться с pcie_aspm=off да крахи сети при гибернации и сне пропали, но с wol поведение не изменилось. Также попробовал различные варианты acpi_osi что находил на виках. Но поведение не менялось.

Shiroe
() автор топика
Ответ на: комментарий от Shiroe

Ночью пока ковырял пришла мысль подкинуть сеть в другой роутер. И после этого у меня теперь появилось ещё больше вопросов чем ответов.

Постараюсь как нибудь ясно описать суть обнаруженного.

Значит, если после падения линка с леновы подкинуть сетевой шнур в другой роутер(назовем его Netis), то линк на Netis появляется и держится (даже получилось разбудить его от туда). Если вставить его обратно в старый роутер (Xiaomi Mir3g) - линка опять нет. Однако если усыплять машину с вставленным кабелем в Netis или вообще без коннекта. А после выключения вставить назад кабель в первый роутер Xiaomi, линк появляется и держится.

Теперь я вообще ничего не понимаю, и связи не вижу. Тут уже пиво не катит, нужно что то покрепче.

Стоит отметить, что на роутере Xiaomi также работают и просыпаются по wol ещё 2 десктопа без проблем. Косяк только с Леново.

И ещё, роутер работает на OpenWrt 19.07.7 r11306-c4a6851c72 / 19.07 branch git-21.069.16534-310f532. Каких либо претензии к прошивке и роутеру ни разу не возникало.

В systemlog видно только то что я описал в шапке, т.е. при гашении машины линк на секунду падает, потом подымается и падает через 7-10 минут.

Mon Mar 29 11:49:29 2021 kern.info kernel: [131402.246830] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
Mon Mar 29 11:49:32 2021 kern.info kernel: [131405.132780] mtk_soc_eth 1e100000.ethernet eth0: port 3 link up
Mon Mar 29 11:56:20 2021 kern.info kernel: [131813.499769] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
Shiroe
() автор топика

Тред не читал, но думаю, что проблема в том, что твой Magic Packet содержит IP-адрес назначения. Попробуй слать пакет без адреса назначения. Если адрес назначения указан, то роутер смотрит в свою таблицу маршрутизации и если он не находит устройства с подходящим IP, то просто не шлет пакет. Если использовать широковещательный адрес, то пакет дойдет до устройства

r0ck3r ★★★★★
()
Ответ на: комментарий от r0ck3r

Не, изначально я это проверял. Тут трабла, что физически пропадает линк, машина <> роутер через 5-10 минут. В эти 5-10 минут будится нормально. Потом нет. Бужу машины всегда по маку, через etherwake. К тому же другие хосты пробуждаются нормально таким макаром без проблем.

Shiroe
() автор топика
Ответ на: комментарий от Shiroe

А кабель пробовал менять? При нахождении в состоянии ожидания WoL линк, насколько я помню, падает в 10 half duplex. Мультикаст в сети есть?

zemidius
()
Ответ на: комментарий от zemidius

Спасибо за наводку, кажется разобрался в чем был косяк. Решил разобрать посмотреть внутрь этой балалайки. Если кратко, пошли микротрещины на ногах Lan порта с внутренней его стороны, причем визуально это не видно. Выяснилось простой прозвонкой между пинами на одном конце кабеля и пятяками куда садится Лан на материнке. Было гуляющее сопротивление от 0 до 900 Ом при дрочке портом. Завез знакомому в мастерскую, он подтвердил что есть проблема. Такого разъема у него не оказалось, но запаяли другой совпадающий по распиновке, пока будет идти подходящий из поднебесной. Приехал домой, затестил, линк уже минут 40 не падает. Вот так вот. Жалко конечно времени потраченного на это всё, все же оказалось дело в железе. Низкий поклон всем кто откликнулся в данном топике. Всем здоровья и бобра. Тему считаю решённой.

Shiroe
() автор топика
Ответ на: комментарий от Shiroe

Блин, а я надеялся, что проблема будет софтовая :( У меня просто похожая трабла с wol, только линк на сетевухе не гаснет.

Khnazile ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.