Ошибка #1002

Не поднимается Wi Fi

Добавил(а) Евгений mashutin почти 6 года назад. Обновлено почти 6 года назад.

Статус:РешенаНачата:08.04.2012
Приоритет:НизкийДата выполнения:
Назначена:Alexei PanovГотовность:

0%

Категория:Система
Версия:16
Bugzilla-Id: Upstream bug:https://bugzilla.redhat.com/show_bug.cgi?id=810773

Описание

После обновления ядра до kernel-3.3.1-2.fc16.x86_64 и kernel-3.3.1-3.fc16.x86_64 беспроводное соединение возможно подключить только с чистой загрузки ноутбука, т.е. если ноут выходит из режимов suspend или hibernate, а так же в случае разрыва соединения Wi Fi (умышленного или нет) снова подключиться к беспроводному соединению невозможно, на экране появляется просьба ввести пароль (см. скрин), потом идет процесс подключения, потом снова просьба ввести пароль и так несколько раз, после чего появляется сообщение о невозможности подключиться к Wi Fi. service NetworkManager restart не дает результата. Восстановить подключение удается только перезагрузкой ноута. Возврат к ядру kernel-3.3.0-8.fc16.x86_64 показал, что в этом случае таких проблем нет и нет Wi Fi работает штатно. Прошу помощи.

01.png (682,699 КБ) Евгений mashutin, 08.04.2012 16:17

var_log_messages (140,034 КБ) Евгений mashutin, 08.04.2012 16:17

lspci-rfr1002.log - lspci -kvvv (15,159 КБ) Alexei Panov, 08.04.2012 16:54

dmesg_после_hibernate (82,861 КБ) Евгений mashutin, 08.04.2012 17:22

dmesg_после_разрыва_соединения_ (75,406 КБ) Евгений mashutin, 08.04.2012 17:22

lspci_-kvvv (15,159 КБ) Евгений mashutin, 08.04.2012 17:22

pm-suspend.log_после_hibernate (8,126 КБ) Евгений mashutin, 08.04.2012 17:22

dmesg_с_параметром_ath9k.debug_0xffffffff_после_загрузки (69,649 КБ) Евгений mashutin, 09.04.2012 00:24

dmesg_с_параметром_ath9k.debug_0xffffffff_после_hibernate (82,764 КБ) Евгений mashutin, 09.04.2012 00:24

dmesg_с_параметром_ath9k.debug_0xffffffff_после_принудительного_отключения_и_включения_беспр._соед. (94,34 КБ) Евгений mashutin, 09.04.2012 00:24

20_custom-ehci_hcd (968 байта) Евгений mashutin, 09.04.2012 00:45

История

#1 Обновлено Alexei Panov почти 6 года назад

  • Параметр Статус изменился с Новая на Обратная связь
  • Параметр Приоритет изменился с Высокий на Низкий
Приложите к задаче логи:
  • "выхлоп" lspci -kvvv;
  • "выхлоп" dmesg после пробуждения;
  • /var/log/pm-suspend.log;
  • /var/log/pm-powersave.log.

#2 Обновлено Евгений mashutin почти 6 года назад

Позже дам все остальные выводы, так как после сна не подключусь к сетке, нужно будет перезапускаться. Кстати, я писал выше, что проблема не только после пробуждения, но и после разрыва соединения.

#3 Обновлено Alexei Panov почти 6 года назад

Не надо постить файлы прямо сюда! Их невозможно читать!
Прикрепляйте файлами.

#4 Обновлено Alexei Panov почти 6 года назад

dmesg после разрыва соединения тоже нужен с параметром ядра ath9k.debug=0xffffffff

#5 Обновлено Евгений mashutin почти 6 года назад

Хорошо, принял к сведению...Здесь то, что вы запросили, вот только /var/log/pm-powersave.log у меня пустой.

#6 Обновлено Евгений mashutin почти 6 года назад

Хочу еще добавить, что на этих ядрах, в отличие от старых, неустойчивый Wi Fi в принципе, так как ни с того ни с сего происходит разрыв связи, который, как уже сказал выше, восстанавливается только после перезагрузки. Раньше такого никогда не было, получается, что ядра, в этом смысле, неработоспособны NM не заточен под них....

#7 Обновлено Alexei Panov почти 6 года назад

"выхлопы" dmesg нужны именно с параметром, который я указал ранее "ath9k.debug=0xffffffff", т.е. с ним надо загрузиться, с ним "уснуть" ноут, с ним же разрыв соединения dmesg приложить.

Также еще вопрос, после того, как сеть перестает подниматься, если выполнить:
modprobe -r ath9k; modprobe ath9k (конечно от root'а)
То соединение происходит?

Увы, но с ath9k в ядрах >3.1 и правда много проблем.

#8 Обновлено Евгений mashutin почти 6 года назад

Запустил ноут с параметром ath9k.debug=0xffffffff, сразу сделал выхлоп dmesg, результат в файле "dmesg с параметром ath9k.debug=0xffffffff после загрузки". Далее ушел в hibernate и вышел из него (как обычно сеть не поднялась), результат в файле "dmesg с параметром ath9k.debug=0xffffffff после hibernate". Далее сделал, как вы сказали, последовательно от root modprobe -r ath9k и modprobe ath9k и, о чудо, сеть поднялась, принудительно выключил ее и опять включил, но сеть не поднялась, сделал опять modprobe -r ath9k и modprobe ath9k сеть появилась, после этого опять принудительно выключил ее и опять включил (сеть не поднялась), снял dmesg, результат в файле "dmesg с параметром ath9k.debug=0xffffffff после принудительного отключения и включения беспр. соед."
Хотелось бы как-то это победить, а то получается, что ставишь обнову и теряешь то, что в общем-то нормально функционировало.

#9 Обновлено Евгений mashutin почти 6 года назад

Может быть это тоже будет полезно, у меня была проблема: "Делаю
  1. pm-hibernate
    Вижу черный подсвеченный экран в левом верх. углу мигает курсор, мигает сек. 40, потом исчезает, слышу работу вентилятора и вижу все тот же черный подсвеченный экран. Жму (удерживаю) кнопку, ноут выключается. Жму опять - ноут просыпается (именно просыпается)!!! Если пытаться войти в ждущий режим, почти то же самое, за исключением, что ноут при нажатии кнопки заново включается. "
    Решил ее тогда так:
    "Создал /etc/pm/sleep.d/20_custom-ehci_hcd содержимое в файле, chmod 755 /etc/pm/sleep.d/20_custom-ehci_hcd.
    После этого появляется спящий и ждущий режимы, но возникает часто ошибка (kernel Disabling IRQ #17) при выходе из них, после чнго вафля наглухо отрубается. Для ее решения добавляем опцию ядра "noirqdebug", т.е. теперь строка ядра в grub.conf такая:
    kernel /boot/vmlinuz-2.6.40.6-0.fc15.x86_64 ro root=UUID=96996fef-9161-4117-a4fb-930b67f68679 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=ru_RU.UTF-8 KEYTABLE=ru rhgb quiet noirqdebug"
    Эту проблему я решал в RFR15 и описывал ее на форуме,но после того как поставил 16 (вчистую), проблема была аналогична и решил я ее так же. Возможно, эта инф-я будет полезна и поможет как-то.

#10 Обновлено Vasiliy Glazov почти 6 года назад

Нашёл баг в апстриме https://bugzilla.redhat.com/show_bug.cgi?id=810773 , похоже это оно.

#11 Обновлено Евгений mashutin почти 6 года назад

Да, похоже, что это он, но решения то нет! !! Еще вопрос, пожалуйста, подскажите, как мне сделать так, что бы при yum update обновлялось бы система, включая ядро, но что бы kernel-3.3.0-8.fc16.x86_64 не удалялось. В первом grub была функция определения кол-ва ядер, здесь что-то во вторм не нашел такой, да и в принципе важно сохранить именно это стабильное ядро, пока не будет решения по данному багу. Спасибо.

#12 Обновлено Vasiliy Glazov почти 6 года назад

Если обновляешься, то текущее (загруженное) ядро не будет удалено. Можешь в этом убедиться в выводе yum.

#13 Обновлено Евгений mashutin почти 6 года назад

Это я знаю. Я имею ввиду, что я обновился тогда, когда система была загружена не с kernel-3.3.0-8.fc16.x86_64, а с другого, как в этом случае сделать, что б не удалилось kernel-3.3.0-8.fc16.x86_64? Есть какой-то инструмент для этого?

#14 Обновлено Vasiliy Glazov почти 6 года назад

Утилита package-cleanup из пакета yum-utils. Прочитай man, там написано как изменить число оставляемых ядер.

#15 Обновлено Alexei Panov почти 6 года назад

Господа, я напоминаю, что это не форум!

#16 Обновлено Alexei Panov почти 6 года назад

Так, значит у меня вот такой "костыль" получается:
1. создаем файл /etc/pm/sleep.d/ath9-workaround.sh со следующим содержимым:

#!/bin/sh
# 

. "${PM_FUNCTIONS}" 

case "$1" in
    hibernate|suspend)
        ;;
    thaw|resume)
        if [ -x /sbin/modprobe ]; then
            /sbin/modprobe -r ath9k
            /sbin/modprobe ath9k
        fi
        ;;
    *) exit $NA
        ;;
esac

2. создаем файл /etc/NetworkManager/dispatcher.d/99-ath9k-workaround с таким содержимым:

#!/bin/sh

if [ "$2" = "down" ]; then
    if [ -x /sbin/modprobe ]; then
    /sbin/modprobe -r ath9k || :
    /sbin/modprobe ath9k || :
    fi
fi

exit 0

3. оба файла делаем исполняемыми.

Перегружаемся, ждем (сперва) отлета соединения и проверяем - соединяется ли сам NM после отлета.
Если все отлично, то проверяем гибернацию.

P.S. Скрипты на работоспособность я не проверял, в них могут быть орфографические ошибки, но по аналогии можно вручную проверить.

#17 Обновлено Евгений mashutin почти 6 года назад

Сделал.... попробовал выкл/вкл. б/с - сработало штатно. Далее ушел в hibernate, из которого уже не вышел: при запуске из hibernate куллер взвыл на макс. оборотах (штатно его вообще не слышно) и продолжал работать так все время, ноут вернул картинку на экране, которая была до выхода в hibernate, курсор мыши двигался, но не позволял что-либо запустить, led питания мигал. Жестко выключился, запустил, куллер опять работал на макс. оборотах, иксы не запустились...Запустил консольный режим, удалил эти скрипты, перезагрузился - иксов нет, куллер на максимуме, led мерцает.. Итак несколько раз, пока не выключил сеть и не выдернул аккумулятор, ноут не запускался в обычном режиме. После того как удалось штатно запуститься, опять создал эти скрипты, удалил /etc/pm/sleep.d/20_custom-ehci_hcd. Перезагрузился, опробовал выкл/вкл. б/с - сработало штатно. Ушел в hibernate: экран погас, куллеры работают, ledы все горят..нажал кнопку вкл/выкл., после чего запустился и ноут вошел в состояние, которое было до hibernate (режим все же сработал, но как-то странно). Вернул /etc/pm/sleep.d/20_custom-ehci_hcd, выключился, загрузил kernel-3.3.1-3.fc16.x86_64 без опции "noirqdebug", опробовал вкл/выкл б/с, несколько раз уходил и выходил в hibernate и suspend, проблем пока не наблюдал буду тестить дальше, все же мало времени прошло для окончательного вердикта.

#18 Обновлено Alexei Panov почти 6 года назад

  • Параметр Upstream bug изменился на https://bugzilla.redhat.com/show_bug.cgi?id=810773

#19 Обновлено Евгений mashutin почти 6 года назад

На текущий момент сбоев не выявлено, даже б/с сама ни разу не разорвалась и, субъективно, даже стабильней вход-выход в hibernate.Спасибо за оперативную помощь. Но все ж, хотелось бы нормальную работу на уровне ядра, без костылей...

#20 Обновлено Alexei Panov почти 6 года назад

  • Параметр Статус изменился с Обратная связь на Ожидание исправления в upstream

Ошибка в upstream есть, слова подтверждения и скрипты я туда приложу, советую подписаться и также подтвердить.
https://bugzilla.redhat.com/show_bug.cgi?id=810773
Ждем исправления.

#21 Обновлено Евгений mashutin почти 6 года назад

Хорошо, напишу туда.. А как узнать, что проблема на уровне ядра пофиксина?

#22 Обновлено Alexei Panov почти 6 года назад

Придет уведомление об обновлении + ошибка в апстрим закроется.

#23 Обновлено Alexei Panov почти 6 года назад

  • Параметр Статус изменился с Ожидание исправления в upstream на Обратная связь

Попробуйте ядро отсюда http://koji.fedoraproject.org/koji/taskinfo?taskID=3980617, исправляет ошибку?

#24 Обновлено Alexei Panov почти 6 года назад

Ошибка также проявляется на модуле b43.
В Fedora 17 новое ядро не помогает.

#25 Обновлено Peter Lemenkov почти 6 года назад

Ждем 3.3.2

#26 Обновлено Alexei Panov почти 6 года назад

...или качаем и ставим:

Евгений нам по прежнему требуется ответ на вопрос с ядром 3.3.2-1 работает?

#27 Обновлено Евгений mashutin почти 6 года назад

Алексей, сейчас проверю 3.3.2.1 и отпишусь.

#28 Обновлено Евгений mashutin почти 6 года назад

Сделал yum update, при этом загрузилось новое ядро 3.3.1-5.fc16.x86_64, скачал 3.3.2-1.fc16.x86_64, но не стал ставить, решил проверить 3.3.1-5.fc16.x86_64, удалил "костыли" и перезагрузился с 3.3.1-5.fc16.x86_64. После загрузки б/с не подключился, стал запрашивать авторизацию, modprobe -r ath9k и modprobe ath9k не помогали. Поставил 3.3.2-1.fc16.x86_64, reboot - все то же самое. Перезагрузился с 3.3.1-3.fc16.x86_64, б/с не подключился, но помогло modprobe -r ath9k и modprobe ath9k, сеть, наконец-то поднялась, опять reboot и уже загрузился с 3.3.2-1.fc16.x86_64 б/с поднялся, 4-5 раз уходил в hibernate и suspend, отключал и подключал б/с - работает штатно (без костылей). Буду тестить дальше, но как-то странно это все завелось...

#29 Обновлено Peter Lemenkov почти 6 года назад

Евгений mashutin писал(а):

Сделал yum update, при этом загрузилось новое ядро 3.3.1-5.fc16.x86_64, скачал 3.3.2-1.fc16.x86_64, но не стал ставить, решил проверить 3.3.1-5.fc16.x86_64, удалил "костыли" и перезагрузился с 3.3.1-5.fc16.x86_64. После загрузки б/с не подключился, стал запрашивать авторизацию, modprobe -r ath9k и modprobe ath9k не помогали. Поставил 3.3.2-1.fc16.x86_64, reboot - все то же самое. Перезагрузился с 3.3.1-3.fc16.x86_64, б/с не подключился, но помогло modprobe -r ath9k и modprobe ath9k, сеть, наконец-то поднялась, опять reboot и уже загрузился с 3.3.2-1.fc16.x86_64 б/с поднялся, 4-5 раз уходил в hibernate и suspend, отключал и подключал б/с - работает штатно (без костылей). Буду тестить дальше, но как-то странно это все завелось...

С 3.3.1 только зря терял время. Надо было сразу 3.3.2 тестить. Но хорошо - значит там действительно поправили.

#30 Обновлено Евгений mashutin почти 6 года назад

Да, пока полет нормальный. Но hibernate как не работал нормально без хука в /etc/pm/sleep.d/20_custom-ehci_hcd, так и не работает и в 3.3.2. Может имеет смысл создать отдельную задачу по этой ошибке?

#31 Обновлено Peter Lemenkov почти 6 года назад

Евгений mashutin писал(а):

Да, пока полет нормальный. Но hibernate как не работал нормально без хука в /etc/pm/sleep.d/20_custom-ehci_hcd, так и не работает и в 3.3.2. Может имеет смысл создать отдельную задачу по этой ошибке?

Да, открывай новую заявку. Это выглядит, как несвязанная с этой проблема

#32 Обновлено Alexei Panov почти 6 года назад

  • Параметр Статус изменился с Обратная связь на Решена

Эту ошибку в таком случае закрываем.

#33 Обновлено Евгений mashutin почти 6 года назад

Ok, всем большое спасибо !

Экспортировать в Atom PDF