Created attachment 4745 [details] dmesg и lspci -k После любого вида suspend'a не подхватывается Wi-Fi. Деталь из dmesg с ath5k: [ 9.914291] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70) [ 2079.669267] ath5k 0000:05:00.0: restoring config space at offset 0xf (was 0x100, writing 0x107) [ 2079.669283] ath5k 0000:05:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xfebf0004) [ 2079.669289] ath5k 0000:05:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) [ 2079.669296] ath5k 0000:05:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107) [ 2089.474603] ath5k phy0: gain calibration timeout (2412MHz)
Это ядерно-драйверная проблема. См. например http://info.solomonson.com/content/phy0-spikes-cpu-and-dmesg-says-ath5k-phy0-gain-calibration-timeout
(В ответ на комментарий №1) > Это ядерно-драйверная проблема. > См. например > http://info.solomonson.com/content/phy0-spikes-cpu-and-dmesg-says-ath5k-phy0-gain-calibration-timeout Не, вот это больше походит: https://bugzilla.novell.com/show_bug.cgi?id=621412#c8
(В ответ на комментарий №2) > https://bugzilla.novell.com/show_bug.cgi?id=621412#c8 Имеет смысл тоже проверить без NM, с одним wpa_supplicant, как там описывают. Я все-таки сомневаюсь, что виноват NM, если только как-то косвенно. С другими драйверами ведь такой проблемы нет.
(В ответ на комментарий №3) > (В ответ на комментарий №2) > > https://bugzilla.novell.com/show_bug.cgi?id=621412#c8 > > Имеет смысл тоже проверить без NM, с одним wpa_supplicant, как там описывают. > Я все-таки сомневаюсь, что виноват NM, если только как-то косвенно. С другими > драйверами ведь такой проблемы нет. Угу, через etcnet работает. Помню только однажды, после перезагрузки почему-то Wi-Fi-карточка перестала видеться вообще, но через несколько включений/выключений она снова стала видна.
Created attachment 4746 [details] dmesg с wi-fi через etcnet и suspend
Created attachment 4747 [details] dmesg после suspend-to-disk При suspend на диск с использованием etcnet также после просыпания wi-fi не поднимается, так что скорей всего дело в ath5k/ядре. Также перезагрузка от этого не спасает - wi-fi также не работает. Спасает только выключение/включение. Для справки: ноут перезагружается только с ключом reboot=p Так что то, что работает при suspend to ram - это, видимо, только потому, что etcnet не трогает wi-fi карточку при этом, а NetworkManager пытается что-то с ней сделать.
Такое поведение проявляется вплоть до 2.6.37-std-ng.
ath5k мне проверять не на чем и не предвидится
Раз std-ng только для личных нужд shrek@, то перевешиваю обратно на std-def.
(В ответ на комментарий №9) > Раз std-ng только для личных нужд shrek@, то перевешиваю обратно на std-def. Попробуйте, пожалуйста, на std-def-2.6.38
Created attachment 4868 [details] dmesg после suspend-to-disk на 2.6.38-std-def Нет, также не работает на этом ядре. В случае, если драйвер ath5k останавливается, то заново он не в состоянии управлять Wi-Fi картой. При suspend-to-ram в кде через виджет "Индикатор батареи" также останавливается драйвер, из-за чего после просыпа wi-fi опять не работает. А при suspend-to-ram по закрытии крышки ноутбука после просыпа wi-fi работает. Но почему-то на второй подряд попытке suspend-to-ram ноут обычно зависает.
(В ответ на комментарий №11) > Но почему-то на > второй подряд попытке suspend-to-ram ноут обычно зависает. Это не относится к 2.6.38.
Пакет kernel-image-std-def удалён из Сизифа заданием 360930.100 (28.10.2024, flavour obsolete), неактуально.
