Сегодня на ядре kernel-image-std-srv-alt15 (система Сизиф x86_64 от четверга прошлой недели) в модуле ath9k словил ошибку (текст перепечатал с фото экрана): Apr 13:08:34:22 pif kernel: [время] ath9k:0.1 Apr 13:08:34:22 pif kernel: [время] ath9k 0000:07:01.0: PCI INT A -> GSI 17(level, low) -> IRQ 17 Apr 13:08:34:23 pif kernel: [время] phy1: selected rate control algorithm 'ath9k_rate_control' [время] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [время] IP: [ffffffffa034f274] ath_startrecv+0x54/0x180 [ath9k] Всё это вместе уложилось в 2 секунды. До этого этот модуль (ath9k с PCI-устройством DLink DWA-547) работал через пятое на десятое, но хоть как-то держал связь с WiFi-точкой (ядро было 2.6.27-std-def-alt15). Я поставил critical из-за NULL в модуле ядра. После ifdown wlan0 модуль ath9k был выгружен, а затем по ifup wlan0 был снова загружен. Я такое сделал из-за того, что ath9k не мог найти несущую частоту: Apr ... pif kernel: [время] ath9k_config: Unable to set channel Apr ... pif kernel: [время] ath_set_channel: unable to reset channel <номер> (<частота>) ... В Windows XP на этом же компьютере связь с точкой стабильная.
Created attachment 3442 [details] Общий снимок экрана Сначала ядро было загружено, после чего ath9k пытается достучаться до WiFi-точки. Я останавливаю командой ifdown wlan0, при этом модуль выгружается (NEVER_RMMOD=no) Даю команду ifup wlan0 и получаю такую ошибку. Перед запуском был выставлен параметр в options: USE_HOTPLUG=yes.
Сергей, а что на текущих std-def?
Сейчас сложно проверить, это USB-адаптер я уже не использую. Скорее всего, можно закрыть без фикса. ath9k со встроенным модулем DLink работает на un-def.
