беспроводная связь отключена аппаратным переключателем даже когда нет

Я знаю, что это собирается походить на неопределенный ответ..., но проверка, чтобы видеть, есть ли у Вас обновленный микропрограммный пакет, установленный для Вашего rt73usb. Это требует, чтобы отдельное встроенное микропрограммное обеспечение было отправлено на устройство, чтобы заставить его работать..., который, конечно, Windows обеспечил бы, затем горячая загрузка позволяет Вам использовать его в Linux.

Я ищу информацию о Fedora относительно недавних rt73usb обновлений драйвера/встроенного микропрограммного обеспечения, но это займет некоторое время.

Проверьте на встроенное микропрограммное обеспечение и обновления этого.

Отсюда, не похоже, что rt73usb-микропрограммный пакет был недавно обновлен (в последний раз был Jan 2012, шесть месяцев назад).

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

Возможно, фаза лунного и Галактического Выравнивания требует этого. Не спрашивайте, иногда это помогает.

Но я все еще подозреваю микропрограммную проблему, так как горячая загрузка в Windows разрешает проблему.

Я подозреваю, что обновление, которое Вы описали, установило некоторую более новую версию драйвера, который не работает совершенно верно с определенными аппаратными средствами, которые Вы имеете. Необходимо просмотреть вкусный журнал /var/log/yum.log и возможно выполненный yum history ища что-либо, что, возможно, влияло на rt73usb драйвер, подсистему usb или другие связанные части (от Вашего lsmod, я посмотрю на что-либо связанное с rt73usb, rt2x00usb, rt2x00lib, mac80211, cfg80211, или rfkill). Отступите любые установки, которые были сделаны примерно в то время, когда вещи начали повреждаться, и посмотрите, начинают ли вещи работать снова.

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

Я полагаю, что проблема связана с обработкой ядра так называемых аппаратных кнопок (который на самом деле мог бы быть полуаппаратными средствами, если они - сенсорные кнопки, не электрические переключатели). Триггеры не могли бы обязательно быть частью беспроводного встроенного микропрограммного обеспечения/драйвера. ACPI мог быть ответственен за это также.

Первая вещь, которую я сделал бы на Вашем месте, попытка перезагрузить к более старому ядру. Если Вы сделали слепое обновление, возможности состоят в том, что ядро было обновлено. Я не знаком с мягкой фетровой шляпой а именно, но я ожидал бы, что ее процедура обновления ядра включает смещающиеся записи GRUB, подобные тому, что делает Ubuntu. Таким образом, для начальной загрузки более старого ядра необходимо было бы ввести GRUB удержанием Сдвига (на раннем этапе начальной загрузки) или нажатие Esc. Затем просто выберите более старое ядро из списка.

Если это "просто не работает", можно далее отладить проблему путем выполнения следующего, и сравнения вывода между поврежденным и работы (зафиксированный путем начальной загрузки окон) состояние ноутбука:

• выполненный dmesg | tail прямо после нажатия кнопки - не могло бы быть ничего связанного там, все же.

• контролируйте ACPI deamon файл журнала - Предположение, что он расположен в /var/log/acpid.log, Вы работали tail -f /var/log/acpid.log.

• выполните отслеживающую событие утилиту такой как xev - Это печатает довольно большой вывод; но единственная вещь, которой Вы интересовались бы, состоит в том, сообщают ли о каком-либо событии нажатия клавиши при нажатии кнопки. (Да, "аппаратная" кнопка могла бы просто отправлять обычные сигналы нажатия клавиши!)

• ищите каталог, связанный с аппаратными кнопками под /proc и /sys, затем cat'луг state файл нашел внизу - можно использовать что-то как find /proc /sys -name "*button*" для этого. Каталог мог альтернативно содержать переключатель или что-то подобное. Можно также просто использовать find /proc /sys -name state, но это также распечатало бы много каталогов, связанных с другим материалом, таких как дисковый контроллер или плата Ethernet.

[113162]Другая проблема, которую я видел здесь, заключается в том, что время от времени ядро не видит событий (либо из-за ошибок в драйверах, либо из-за проблем с аппаратной частью).

Одним из критических шагов в диагностике является запуск:

А затем включение и выключение, убедившись, что вы видите такую строку:

• При включении и выключении вы должны увидеть такую строку:

• Обратите внимание на [113565]жесткий 0[113566] в конце. Если вы этого не видите, ядро не увидело события.

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

We have found that sometimes the BCD file may have issues.

You can try this to fix the BCD file.



1. Run CMD.EXE as administrator

2. Run the following command: bcdedit -enum all

   Look for "Resume from Hibernate" in the output from the command above(example below):

   Resume from Hibernate

   ---------------------

   identifier {3d8d3081-33ac-11dc-9a41-806e6f6e6963}

   device partition=C:

   path \Windows\system32\winresume.exe

   description Windows Vista (TM) Enterprise (recovered)

   inherit {resumeloadersettings}

   filedevice partition=C:

   filepath \hiberfil.sys

   pae Yes

   debugoptionenabled No

3. Once you have found it, copy the value for identifier (in this example - {3d8d3081-33ac-11dc-9a41-806e6f6e6963})

4. Run the following command: bcdedit /deletevalue {3d8d3081-33ac-11dc-9a41-806e6f6e6963} inherit

5. Test hibernation.


Thanks,
Darrell Gorter[MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights

Вы можете проверить, что rfkill на самом деле показывает события, используя комбинацию клавиш для отключения беспроводной связи, и убедиться, что вы видите [113567]мягкое 1[113568] событие, а затем, когда вы снова включаете, вы должны увидеть [113569]мягкое 0[113570] событие. Если переключатель не работает, вы можете использовать его до тех пор, пока он не заработает, записать его на пленку в положении "включено" и т.д. или просто получить вторичный сетевой адаптер.

• Естественно, если вы не видите события, то это может быть либо аппаратный, либо программный сбой. Однако, когда я видел это в последний раз, это был неудачный (но не полностью неудачный) аппаратный коммутатор.[113177]