Есть у меня на буке Wi-Fi карточка:

02:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100

Так вот, после апдейта ядра где-то в районе 2.6.30 -> 2.6.31 периодически стал отваливаться Wi-Fi. Точнее отказывался подниматься:

dion@laptop:~% sudo ip link set wlan0 up
RTNETLINK answers: Unknown error 132

Код 132 гуглится как запрет из-за rfkill-а. При этом аппаратным переключателем Wi-Fi включен. Разобраться с этим было лень, хватало обычно просто сделать s2ram и проснуться.

Сегодня таки открыл для себя тулзу под названием rfkill, которая умеет показывать статусы этих переключателей:

dion@laptop:~% sudo rfkill list
0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Аппаратный переключатель меняет флажок “Hard blocked”. Кто блокирует “Soft blocked” я так и не понял. Но rfkill’ом можно этот “Soft blocked” снять:

dion@laptop:~% sudo rfkill unblock wifi
dion@laptop:~% sudo rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

После этого Wi-Fi начинает работать.

Только что впоймал на /home:

[100992.424959] REISERFS warning: reiserfs-5090 is_tree_node: node level 32768 does not match to the expected one 1
[100992.424971] REISERFS error (device dm-5): vs-5150 search_by_key: invalid format found in block 6750427. Fsck?
[100992.424978] REISERFS (device dm-5): Remounting filesystem read-only

Выше в логе ничего вроде ошибок чтения нету. Винт судя по SMART-у живой.

Ребутнулся, сделал fsck, тот только журнал навернул, но так и не нашел ничего. Странно как-то. Возможно связано с s2disk.

Давно я не пользовался USB-ным 3G модемом. Сегодня вот обнаружил, если выдергивать мопед при запушенном pppd, то девайс /dev/ttyACMx не удаляется. Аналогично при s2ram с поднятым pppd. Соответственно перевтыкивание модема создает новый ttyACM. При этом open() на старые говорит “No such device”, что вполне логично.

Раньше такого точно не было. Странно как-то.

Собрал себе свежее ядро. После загрузки отвалился тачпад на ноутбуке. Точнее не отвалился, а перестали работать всякие вкусности вроде скроллинга, нажатий одним/двумя/тремя пальцами.

Раньше он определялся просто как PS/2 мышь, все эти фичи, как я понимаю, у него реализованы аппаратно. Теперь оно выглядит как “ETPS/2 Elantech Touchpad” и, по идее, должно работать с иксовым драйвером “synaptics”. Но, как оказалось, не работает.

Нагуглилось, что нужен synaptics из X.org версии 1.5, а в Debian Unstable еще 1.4. Поставил из experimental. Всё равно не завелось. Вот тут написали:

The Debian archive presently does not contain a new-enough version of xserver-xorg-input-synaptics; 0.99.1 or later is needed (0.99.3 is current). 0.99.2 is available in packaged form from http://alioth.debian.org/~dsalt-guest/eee/ (you'll need to use dpkg -i to install it). [Correct as of 2008-12-27.]

Пакет по указанной урле на X.org 1.5 не ставится. Пересобрал версию 0.99.3. Поставилось. Нарисовал в xorg.conf секцию InputDevice, указав что используем synaptics. Загружаю иксы, все вкусности тачпада продолжают неработать.

Полез в логи. Вижу, что грузится synaptics, определил тачпад, сказал что его поддерживает и всё хорошо. И тут, непонятно зачем и почему, начинает выпендриваться hald:

(II) config/hal: Adding input device ETPS/2 Elantech Touchpad                                       
(II) LoadModule: "evdev"

Я конечно понимаю, что выгребание настроек про железо из HAL — это типа круто, но какого черта это должно быть приорететнее руками указанной секции “InputDevice”?

Первым делом попробовал самое простое: снес xserver-xorg-input-evdev. Иксы запустились, тачпад работает, но перестала работать клавиатура и USB-ная мышь. Вернул пакет на место и сел разбираться с hal.

Если теперь _это_ предлагается в качестве замены xorg.conf, то это клиника. Вместо одного файла теперь это куча размазаных по /usr и /etc конфигов, при чем в офигеть каком user friendly формате — XML. Те куски XMLя, которые лежат в /usr ковырять, как бы, нельзя, ибо при обновлении затрется. Соответственно нужно копировать в /etc и править уже там.

После чтение мануалов у меня вышло примерно следующее:

  
    
        synaptics
        True
    1
    2
    3
    1
    1
    1
    
  

Раза в три больше кода, чем для случая с xorg.conf. Тем не менее, после рестарта hald, тачпад таки заработал.

X.org 1.5 вроде относительно стабилен, не считая того, что падает после запуска KDE4, если включено композитное расширение. На nV News посоветовали отключить BackingStore. Помогло.

Пропатчил Psi. Выключил в KDE4 вывод звука через Xine. Выкинул нафиг mpd… Поставил вместо него xmms2. Теперь в powertop из процессов только иксы видны…

  18.5% ( 48.7)       : Rescheduling interrupts
  18.1% ( 47.7)   USB device  1-3 : USB to ATA/ATAPI Bridge (JMicron)
  17.8% ( 46.9)        : HDA Intel
   7.6% ( 20.1)        : ehci_hcd:usb1, ohci_hcd:usb2
   7.0% ( 18.3)              Xorg : schedule_timeout (process_timeout)
   4.9% ( 12.8)   USB device 1-8.1 : USB Keyboard (Chicony)
   4.1% ( 10.8)        : extra timer interrupt
   4.0% ( 10.6)        : 0000:05:09.0

Если выключить звук, то через ~10-15 секунд выделенными остаются только Wi-Fi, Xorg и нечто под названием ehci_work.

Чего-то у меня с 2.6.27-rc5 какие-то странные вещи в top-е стали показываться…

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25799 dion      20   0 29016  11m 9696 S  713  0.6  13:48.34 kpowersave
25925 dion      20   0 78564  27m  14m S  426  1.4  11:43.79 assistant-qt4
 5429 root      20   0  4828 1736 1428 S  395  0.1   2:02.39 powersaved

Или вот так:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 8430 dion      20   0 57544 4940 2836 S  218  0.2  16:33.68 xmms2d
25841 dion      20   0  122m  68m  18m S  140  3.4 148:30.88 konsole
25746 dion      20   0 64064  20m  14m S  133  1.0  99:58.73 kwin

Если потыцкать Enter, то %CPU иногда и четырехзначным бывает. При чем у нескольких процессов сразу.

Кроме как особенностей рабочего CONFIG_NO_HZ идей у меня нет… В powertop-е этих процессов не видно…

Решение таки найдено… В LKML запостили серию патчей, которые фиксят это. Пропатчил 2.6.27-rc5. Все работает..

Более того, с C1E нормально заработал CONFIG_NO_HZ. В powertop-е теперь практически не видно “лишних” просыпаний проца… Теперь наиболее часто просыпаться заставляют Xorg, Psi и knotify4. С последним — уже пофиксено в транке KDE (#156215).

Что делает заставляет просыпаться Psi я пока не разобрался… Чуть поигрался с strace и gdb. Это обычный Qt-ный event loop. Поковыряюсь позже.

Стянул TuxOnIce из git-а Nigel-а. Смержилось без конфликтов и даже работает.

Поигрался с powertop-ом. Посмотрел, как влияет включение C1E на потребляемую мощность от батареи.

Есть тут в BIOS-е такая штука под названием “Advanced powersaving”. Что оно делает, нигде не написано, но от батареи ноут с ней работает чуть дольше. То есть оно таки что-то делает. Для 2.6.25, при загрузке с этой опцией и без нее, различие заключается в следующей строке в dmesg:

AMD C1E detected late.  Force timer broadcast.

Так вот, выключение этой самой опции в BIOS-е чинит загрузку ядра 2.6.26. Получается, что с этим самым advanced powersaving ядро не грузится вообще, а без него — работает как положено.

Нагуглилось два треда в LKML по этому поводу: http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg240281.html — декабрь 2007 http://thread.gmane.org/gmane.linux.kernel/693198 — июнь 2008.

Первый — какой-то костыль для отключения C1E (очевидно для тех BIOS-ов, в которых этот самый Advanced powersaving неотключаем).

Второй — фиксит что-то в этом районе. Патчи для 2.6.26-rc5. Если к релизу приложатся, посмотрю, поможет или нет.

TODO: померять, на сколько этот C1E экономит батарею (например с помощью powertop).

Собственно вот

9713277607f9eac7d655c6854dd92bc2ce1b6f02 is first bad commit
commit 9713277607f9eac7d655c6854dd92bc2ce1b6f02
Author: Glauber de Oliveira Costa <gcosta @redhat.com>
Date:   Wed Mar 19 14:25:43 2008 -0300

    x86: boot cpus from cpu_up, instead of prepare_cpus

    After all the infrastructure work, we're now prepared
    to boot the cpus from cpu_up, and not from prepare_cpus.
    So the difference between cold boot and hotplug is effectively
    over, and the functions are used to the purposes they're meant to.

    Signed-off-by: Glauber Costa <gcosta @redhat.com>
    Signed-off-by: Ingo Molnar <mingo @elte.hu>

:040000 040000 c191cf15825af14a8f4e2842105c33e19ad9df1d 3a6e4c6a5489a20722e83c98204f16d29bdc01fd M      arch

bisect рулит. Достаточно быстро разгреб 10k коммитов. Спасибо TuxOnIce за то, что не пришлось полностью перезагружать машину после каждой сборки :)