ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Не работает Wi-Fi после suspend to disk на asus X50N | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Rinat Bikov <bikr> | ||||||||||
| Component: | kernel-image-std-def | Assignee: | Vitaly Chikunov <vt> | ||||||||||
| Status: | REOPENED --- | QA Contact: | qa-sisyphus | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | becase, kernelbot, placeholder, sem, vt | ||||||||||
| Version: | unstable | ||||||||||||
| Hardware: | all | ||||||||||||
| OS: | Linux | ||||||||||||
| Attachments: |
|
||||||||||||
Это ядерно-драйверная проблема. См. например 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. |
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)