Инструменты пользователя

Инструменты сайта



// Странная проблема с WiFi на EeePC 1000HA

Проблема сводится к тому, что при запуске Xorg связь начинает умирать. Для восстановления достаточно переключиться в консоль. Причины и связи мне не понятны, и вообще фантастически выглядит решение проблемы: перепрошивка точки доступа. Вот где тут связь???

Пока разбирался, научился запускать драйвер ath5k - просто для его включения нужно активизировать 2 rfkill устройсва:

  1. сначала eeepc-wlan (см вывод rfkill list)
  2. после появится ещё одно - phy0, и активировать его
  3. затем, в обязательном порядке - ifconfig wlan0 up

после чего можно начинать работать.

Точка доступа (DWL-G700AP) же, была последним шагом - нет нормальной связи, так хоть поэксперементирую. Прошивку туда залил Wive-ng, она на базе ядра Linux 2.4, и очень значительно расширяет возможности точки, превращая её в полноценный маленький сервер с управлением по ssh/telnet:

  • pppoe-client
  • pptp-client
  • dhcp
  • iptables/nat
  • балансировка трафика
  • роуминг (прозрачный переход от точки доступа к точке доступа)
  • vlan
  • широкий диапазон регулировки мощности (больше чем в базовой поставке, но для значений больше 20, следует применять принудительное охлаждение)
  • smbclient (но… не могу представить для чего :) если бы было память побольше, можно было бы туда запихнуть rtorrent с веб-интерфейсом (или даже без оного), а так…)
  • и ещё всего и вся по мелочи

В результате и связь при запущенных Xorg поднялась. Хитрая уличная магия.

По прошивке и вообще точке доступа:

General:

Wive:

Wive-ng:

// Mplayer и отсутствие xv

В продолжении этой темы вывод видео с -vo xv не увенчается успехом, и в X11 будет использоваться, по умолчанию, драйвер x11 - минус ровно один: не масштабируется видео к полному экрану. И xvinfo вас не порадует…

Вспомнил свою бытность на P100 и мало-мало памяти:

  • вывод видео через sdl
  • вывод audio через sdl
  • кеширование
  • и т.п.

В результате, получился такой конфиг ~/.mplayer/config

# видео-выход, посмотреть возможные: mplayer -vo help
vo=sdl
# audio-выход, посмотреть возможные: mplayer -ao help
ao=sdl
# Автоматическая синхронизация аудио и видео - следитие за процессором, на некоторых просто не успевает видео в высоком качестве декодироваться, отсюда возникает причина задержки, такое  лечится только апгредом
autosync=100
# Предварительное кеширование, для проигрывания интернет радио задавайте 512-1024, не больше
cache=8192
# ну это украшательство, просто цветной вывод, т.к. mplayer использую консольный, глаз рудается, да.
msgcolor=true

Ну в общем, в отсутствии xv такая конфигурация работает довольно прилично, правда видео в высоком разрешении ещё не проверял, но, как мне кажется, нетбук не для того предназначен.

ЗЫ с помощью -vo fbdev или -vo fbdev2 (кстати, чем они отличаются?) можно смотреть видео в консоли с фрейм-буффером, а с помощью -vo aa (ч/б) или -vo caca (более продвинуто) - втыкать видео в псевдографике.

// EeePC: uvesafb + родное разрешение в консоли и X11

Пришло время ядра 2.6.32 (уже 2.6.32.3) в core репозитория ArchLinux, да вот незадача: поломали они графику.

Проявляется так: через некоторое время работы, в иксах начинает дергаться экран, как в дерьмовом фильме, где после крутого взрыва на космическом корабле все мониторы взорвались, а последний, для связи с Землей, перед последним вздохом показывает дерганное изображение оператора с того конца. Еще через некоторое время графика фризится, на некоторых версиях иксовых дров (2.9.1) это финиш, для тех что из git - можно переключиться в консоль и там вырубить иксы, да вот запустить их не получится до полной перезагрузки. Да это не паника - система продолжает работать.

Если задать опцию powersave=0 для модуля i915, проявление вышеописанных багов несколько снижается, но не исчезает. Кроме того, после suspend-to-ram фейл появляется почти сразу.

Подумав, решил на время отказаться от родных драйверов в сторону vesa, мне главное нормальная и стабильная работа (да, Арч, что бы моск не заплыл :))

Собственно, все свелось к следующему

Для начала ставим пакет v86d из extra:

pacman -S v86d

После установки редактируем файл /etc/modprobe.d/uvesafb.conf на предмет нужного нам разрешения экрана, ставим сразу (верно для моего EeePC 1000H) 1024×600-32

И загружаем модуль usevafb:

modprobe uvesafb

Ииии облом :) получим разрешение 800×600 и растянутое изображение - приятного мало.

Связано с тем, что видеобиос на некоторых чипах не поддерживает переключение в нативное разрешение, глюк, согласно статье в вики: http://wiki.archlinux.org/index.php/Uvesafb#Uvesafb_and_915resolution

Там же находим способ как обходить - использовать хак под названием 915resolution лежит он в AUR, только берите версию 915resolution-static - там содержится патч для поддержки 945GME. Собираем этот пакет и ставим.

Дальше запускаем: sudo 915resolution -l

смотрим какие режимы предоставляет. Я для переопределения под номером 54 (в hex виде) - бывший 1024×768-32.

Если поддержки чипа нет - то будет об этом сказано, в этом случае - гуглите, патчите.

Дальше, нужно соблюдать порядок:

  • сначал хачим биос:
    915resolution 54 1024 600
  • потом уже загружаем модуль uvesafb:
    modprobe usevafb

    (при наличии настройки в /etc/modprobe.d/uvesafb.conf)

В случае ArchLinux данную загрузку можно осуществить через initrd, для этого:

  1. редактируем хук: /lib/initcpio/hooks/915resolution на предмет нужного режиме (смотрим выше что написал, про хачим биос)
  2. редактируем /etc/mkinitcpio.conf и дабавляем в строку HOOKS следующие хуки: 915resolution и v86d (сначала первые потом второй - порядок важен)
  3. запускаем:
    mkinitcpio -p kernel26

Все, при перезагрузке все станет на свои места, либо вручную вызвать нужные команды. Кстати на официальном сайте uvesafb есть информация (http://dev.gentoo.org/~spock/projects/uvesafb/faq.php) как при работе выключить фреймбуфферную консоль и вернуть текстовую моду:

Can I unload the uvesafb module and switch back to a text mode?

Yes, provided your Video BIOS supports saving the VBE state. This is supported by the vast majority of the currently available BIOS-es. If yours does not support this feature, you will get an appropriate warning in the kernel log. In order to switch back to a text mode, you will need to detach fbcon: echo 0 > /sys/class/vtconsole/vtcon1/bind (make sure the VT_HW_CONSOLE_BINDING kernel config option is selected, otherwise this will do nothing). After you do that, you should be automatically switched back a text mode console. You will also be able to unload uvesafb and fbcon if they have been built as modules.

Уже мы все такие радостные, да? :) а теперь сделайте suspend-to-ram, ога, у меня не проснулось :) точно проснулось но графика слетела. В попытках исправить (для засыпания использую pm-utils с модулем uswsusp) поместил два скрипта в /etc/pm/sleep.d

  • скрипт 10_915resolution:
    #!/bin/bash
     
    case $1 in
        hibernate|resume)
        /usr/sbin/915resolution 54 1024 600
        ;;
    esac
  • скрипт 10fbcon:
    #!/bin/bash
     
    case $1 in
        hibernate|resume)
        echo 0 > /sys/class/graphics/fbcon/subsystem/fb0/state
        ;;
    esac

Первый запустит хак, т.к. после сна/гибернейта он имеет тенденцию сбрасываться, а система находится в тупняке - а чо происходит то! Второй, скорее традиция - когда после сна консоль не просыпалась, исправляло ситуацию.

В общем, пока все, огромная просьба - протестить, отписаться.

Да! после сна, бывает черный экран - переключаемся в консоль и обратно. И для иксов достаточно прописать нужный режим (Modes «1024×600») и драйвер vesa.

ЗЫ жду когда родные дрова починят, поставил бы Торвальдс Арч, что ли :)

// NetworkManager

Все или подавляющее большинство дистрибутивов предоставляют средства для конфигурации сетевых подключений. Это удобно делать на стационарном компьютере, но что если у вас ноутбук и приходится работать в разных сетях, да ещё быстро настраивать WIFI, тут должны помочь менеджеры сетевых подключений, для быстрой настройки и ввода в строй.

Это пост-размышление и попытка найти золотую середину.

Итак, исходное: нетбук Asus EeePC 1000H, дистрибутив ArchLinux, из тех менеджеров, что можно найти в стандартных репозитариях: networkmanager, wicd, nuts (в AUR или в чакра-проджект).

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

wicd

Исторически так сложилось, что это был первый мененджер сетевых подключений, который я использовал. Он меня всем устраивал, даже тем, что можно было указать только под одному сетевому интерфейсу для проводной и беспроводной сети. Все, больше ничего лишнего: не VPN, не PPPoE, ни подключения телефона и т.п. Только управление профилями проводных и безпроводных (WIFI) сетей.

Изначально обладал только графическим клиентом - wicd-client, в последних версия обзавелся и консольным - wicd-curses, и все бы было хорошо, если бы не написан на питоне (есть у меня предубеждения к этому языку, считаю его идеальным для обучения хорошему стилю кодирования, но не как не для создания полноценных приложений, по сути, в мире *nix он стал эквивалентом Visual Basic для Windows).

Ладно, мне главное ехать, а не шашечки. Но в какой-то момент времени стали наблюдаться непонятные события - при отключении сетевого подключения (например если просто вынуть кабель) долгие тормоза, при этом от системы никакого отклика. Те же события при подключении, причем, я не могу выловить закономерности (мало-мало грешу на флеш в Firefox, конкретно - всякие ролики типа с Ютуба). Это меня сподвигло на поиск альтернативы.

NetworkManager

Логичной альтернативой стал NetworkManager, разработанный в рамках проекта Gnome. Исследуя его зависимости, оказалось, что сам демон (NetworkManager) от gnome никак не зависит, а вот с клиентами чуть каша (про это позже).

Краткие возможности: написан на Си, что несколько радует, позволяет настраивать сеть по нескольким сетевым интерфейсам, как проводным так и беспроводным, позволяет настраивать соединения по PPPoE, поддерживает настроку VPN (OpenVPN, pptp и ещё что-то), но через допольнительные плагины (которые требуют, для чего-то, установленного network-manager-applet)

Стандартный клиент - gnetwork-manager-applet (вызывается nm-applet), встраивается в системный трей, откуда можно вызвать и конфигуратор, имеет гномовские зависимости: gnome-keyring, policykit-gnome, notification-daemon

Есть клиент для KDE - knetworkmanager, к сожалению есть только в AUR7) и только для KDE3

Для консоли, клиент cnetworkmanager-git или cnetworkmanager, опять таки только в AUR8). Клиент написан на питоне.

В общем, GUI клиента без лишних DE зависимостей пока найти не удалось, так что если кто предложит, написанный только на QT/Gtk, буду благодарен, а пока наблюдаю работа в nm-applet.

nuts

Орешки :) Но пока я его не расколол - в клиенте так и не увидел ни одного профиля. Из минусов программы: жесткая настройка сетевых профилей в конфигурационном файле, но работать может с несколькими интерфейсами. В комплекте графический клиент на QT4 - qnut и консольный - cnut.

Доступен из AUR9) или из репозитариев чакра-проджект10), для отстройки нужен пакет kdemod-openresolv11) и хотя оба пакета в своём названии содержат kdemod, никаких kde зависимостей они не тянут12).

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

// EeePC: 2.6.31.4 + wifi

EeePC 1000HA, wifi, карторчка Atheros (чип - AR2425, согласно этому, это AR5007EG, хотя lspci называет её как AR5001), ядро 2.6.31.4

возможные драйвера:

  • ath5k - стоковый
  • madwifi-hal - из AUR
  • ndiswrapper - из core + виндовый драйвер (нужны *.sys и *.inf файлы)

Поведение:

ath5k
У меня вообще отказался нормально работать, соединение устанавливается только при перезагрузке системы, после, если выгружать подгружать драйвер, ноль реакции.

UPD: с какой-то версии ядра данный драйвер стал прекрасно работать, сейчас, на 2.6.36 он прекрасно трудится и не чихает. Немного можно почитать тут

madwifi-hal
Работает. Не сумел завести карточку в режиме 802.11g, хотя она это поддерживает, как и точка доступа. Скорость крайне медленная, меньше 1 мбита, хотя точка в 1.5 метрах. Иногда бывают затыки, потом на короткое время соединение опять поднимается.

ndiswrapper
наконец дошли руки попробовать, точне довело: раньше нормально работал madwifi-hal, поставил, особо ничего трудного, в вики есть немного информации. Карта встала как 802.11g, скорость в выводе iwconfig светится как 54Mbit, но, судя по всему, сумма в обе стороны, скачка большого файла с сервера идет со скоростью примерно 2.7 Мбайт/сек, что примерно равно 24мбит. Пока ещё наблюдаем, надеюсь, с madwifi-hal что–то сделают.

UPD: а у этого способа оказался свой косяк: убивается, со временем, шина USB, перестаёт реагировать мышка, принудительная выгрузка модулей помогает, но следующий слет USB приводит к Kernel Panic

Настройка

Для настройки сетевых подключений использую wicd, остальные настройки, ниже.

ath5k/ath9k

ath9k драйвер используется для новых карточек 802.11n

  1. /etc/rc.conf:
    MODULES=(... !ndiswrapper ath5k !ath_hal !ath_pci ...)
  2. /etc/modprobe.d/wifi_balacklist.conf:
    blacklist ndiswrapper
    blacklist ath_hal
    blacklist ath_pci
  3. при использовании acpi-eeepc-generic, /etc/conf.d/acpi-eeepc-generic.conf:
    WIFI_DRIVERS=("ath5k")

madwifi-hal

  1. скачиваем из AUR: http://aur.archlinux.org/packages.php?ID=20857, распаковываем, строим, устанавливаем, без подробностей.
  2. /etc/rc.conf:
    MODULES=(... !ndiswrapper !ath5k ath_hal ath_pci ...)
  3. /etc/modprobe.d/wifi_balacklist.conf:
    blacklist ndiswrapper
    blacklist ath5k
    blacklist ath9k
  4. /etc/modprobe.d/madwifi.conf:
    options ath_pci autocreate=sta ratectl=minstrel countrycode=0 xchanmode=1 intmit=1 ath_debug=1 ieee80211_debug=1

    вы можете поиграться с этими опциями, посмотреть можно по modinfo ath_pci

  5. при использовании acpi-eeepc-generic, /etc/conf.d/acpi-eeepc-generic.conf:
    WIFI_DRIVERS=("wlan_tkip" "wlan_ccmp" "ath_pci" "ath_rate_sample" "ath_hal" "wlan_scan_sta" "wlan")

ndiswrapper

Пока использую его на последнем ядре.

  1. Устанавливаем ndiswrapper и ndiswrapper-utils
  2. /etc/rc.conf:
    MODULES=(... ndiswrapper !ath5k !ath_hal !ath_pci ...)
  3. /etc/modprobe.d/wifi_balacklist.conf:
    blacklist ath_pci
    blaclist ath_hal
    blacklist ath5k
    blacklist ath9k
  4. распаковать виндовый драйвер (можно взять отсюда последний: http://www.atheros.cz), выполнить команды от рута:
    ndiswrapper -i netathw.inf
    ndiswrapper -l
    ndiswrapper -m
  5. при использовании acpi-eeepc-generic, /etc/conf.d/acpi-eeepc-generic.conf:
    WIFI_DRIVERS=("ndiswrapper")

// Asus EeePC 1000HA и AHCI

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

Для начала выяснилось, что жесткий диск у меня SATA, а не IDE и поддерживает NCQ. Вот его включить и захотелось.

// ArchLinux: делаем UXA акселерацию на Intel 945GME

Итак, у нас тут последовали значительные обновления в системе:

  • ядро 2.6.29
  • oxrg 1.6.0
  • xf86-video-intel 2.6.3

В новых драйверах для xorg появилась возможность использовать акселерацию UXA, вопрос - как её получить?

А просто.

// EeePC и обновление до ядра 2.6.28

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

  • некорректно работает тачпад в иксах
  • странно работает wifi

Итак, по порядку…

Elantech Touchpad

Input устройства у меня подключены через hal, соответственно в /etc/hal/fdi/policy лежал (да и лежит) файлик 09-x11-elantech.fdi вот только беда, после обновления он вроде как не цепляется (точнее это я понял потом, что он не цепляется).

Симптомы такие:

  • «дерганное» передвижение курсора в иксах, отсутствие реакции на слабые перемещения по тачпаду
  • при переключении из иксов в консоль и обратно: курсор вообще перестает двигаться, в консоли наблюдаем: FIXME
    (EE) EXPS/2 Elantech Touchpad: ... - disabled

Причины, трудно сказать кто конкретно - hal или ядро, но внутри fdi была строчка:

<match key="info.capabilities" contains="input.touchpad">

посмотрев вывод hal_device я обнаружил, что у тачпада в списке capabilities нет строки input.touchpad, есть только input и input.mouse, поэтому вышеуказанная строчка приобрела вид:

<match key="info.capabilities" contains="input.mouse">

и полный fdi стал такой:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.mouse">
        <match key="info.product" contains="Elantech Touchpad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
        <merge key="input.x11_options.SHMConfig" type="string">on</merge>
        <merge key="input.x11_options.MaxSpeed" type="string">1.00</merge>
        <merge key="input.x11_options.MinSpeed" type="string">0.75</merge>
        <merge key="input.x11_options.Emulate3Buttons" type="string">on</merge>
        <merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge>
        <merge key="input.x11_options.HorizTwoFingerScroll" type="string">1</merge>
        <merge key="input.x11_options.TapButton1" type="string">1</merge>
        <merge key="input.x11_options.TapButton2" type="string">2</merge>
        <merge key="input.x11_options.TapButton3" type="string">3</merge>
        <merge key="input.x11_options.LockedDrags" type="string">11</merge>
      </match>
    </match>
  </device>
</deviceinfo>

после чего делаем /etc/rc.d/hal restart и, на всяк, перезапускаем иксы. Всё, работа восстановлена.

Wifi

Тут вспомнил, что на archlinux.org.ru проскакивала информация, что драйвер переделан для совместимости с rfkill.

Раньше карточку можно было включать/выключать записывая 1 или 0 в /sys/devices/platform/eeepc/wlan, теперь же это нужно делать через /sys/class/rfkill/rfkill0/state, соответственно нужно подправить конфиг для acpi: /etc/acpi/eee.conf (смотреть предыдущие статьи).

Но и это не всё.

К сожалению, одно сделали - другое поломали, т.е. раньше драйвер eeepc_laptop знал - включена или нет wifi карта и, соответственно, генерировал на нажатие Fn + F2 разные последовательности.

Теперь он не знает. Поэтому пришлось сделать небольшой хак (надеюсь временный), основанный на сиквенс-намбере нажатия - делим на 2 и получаем остаток, если 0 - выключаем карту, если 1 - включаем.

Что бы это работало - меняем файл /etc/acpi/eee-handler.sh, находим где обрабатываются hotkey (строчка «hotkey)») далее ищем «00000010) # wlan on» комментируем строку

#/etc/acpi/eee/wlan.sh poweron

и прописываем вот такие команды

# some hack for 2.6.28 stock kernel
rez=$(( 0x$4 % 2 ))
[ $rez -eq 0 ] && /etc/acpi/eee/wlan.sh poweroff
[ $rez -eq 1 ] && /etc/acpi/eee/wlan.sh poweron

неприятно что asusosd будет постоянно говорить что wifi включается :(

В заключение

Нашел вот это:

новые темы в вики, на форуме и в AUR касательно Asus EeePC 1000

// EeePC: dpi & wifi

В продолжение изначальной темы про мой EeePC. Разберем вопрос правильного задания DPI и как пользоваться WIFI и вообще сетью на ноутбуке.

DPI

Как задавать DPI (dots per inch / точек на дюйм) рассказано в статье про установку Arch Linux на EeePC 901 (смотреть мой первый пост про EeePC на этом блоге или пользоваться поиском на ArchWIKI). Я же хочу разобраться как получить это значение вообще, и какое оно будет для EeePC 1000HA, в частности.

Итак, разрешение матрицы монитора X на Y точек (пикселей). Тогда количество точек по диагонали:

Z = sqrt(X^2 + Y^2)

Диагональ монитора D дюймов, тогда значение DPI:

DPI = Z / D

Округляем его до большего целого.

Для EeePC имеем разрешение матрицы 1024×600 пикселей и диагональ 10.2 дюйма:

Z = sqrt(1024^2 + 600^2) = 1186.8
DPI = 1186.8 / 10.2 = 116.36 ~ 117 dpi

Иногда встречается информация, что диагональ 10 дюймов… спорить не берусь, меня пока всё устраивает :)

А для моего ThinkPad T530 (15.6 inch, 1920×1080):

Z = sqrt(1920^2 + 1080^2) = 2202.90717
DPI = 2202.90717 / 15.6 = 141.21 ~ 141 dpi
Width = 15.6 / 2202.90717 * 1920 * 25.4 = 345.35 ~ 345 mm
Height = 15.6 / 2202.90717 * 1080 * 25.4 = 194.26 ~ 194 mm

Прописываем полученное значение в /etc/X11/xinit/xserverrc, где строчка запуска превращается примерно в такое:

exec /usr/bin/X -nolisten tcp -dpi 117 "$@"

При использовании всяких mdm, gdm, kdm и иже с ними, нужно параметры запуска Xserver искать у них в настройках. Плюс, при таких настройках строчка ниже упорно рапортует о 96dpi. Зато в логах Xorg.0.log гордо красуется 141 (это уже новый ноутбук). При конфигурировании через xorg.conf картина с точностью до наоборот.

Перезапускаем, проверяем при помощи xdpyinfo:

xdpyinfo | grep -B2 resolution:

На картах nVidia (это уже не про EeePC :-)) есть опция для драйвера DPI, использовать её как-то так:

Section "Device"
    Identifier          "Card0"
    Driver              "nvidia"
    ...
    Option              "UseEdidDpi"   "false"
    Option              "DPI"          "141 x 141"
EndSection

Для других карт поможет DisplaySize в миллиметрах (сохраняем, например, в /etc/X11/xorg.conf.d/90-monitor.conf):

Section "Monitor"
	Identifier "<default monitor>"
	DisplaySize 345 194 # посчитали выше
EndSection

Более подробно:

WIFI

Хотя не только он, но больше про него.

Первое, говорится что стандартный драйвер не очень хорошо работает, я не стал проверять, поставил madwifi-hal из AUR. Надо только занести модуль ndiswrapper в blacklist или вообще удалить пакеты ndiswrapper и ndiswrapper-utils (если были поставлены). Если с драйвером madwifi-hal карточка не заведется, то, как рекомендуют форумы, стоит попробовать родной драйвер ath5k, и наоборот.

Да, я думаю пакет acpi-eee901 у вас уже стоит, так вот, стоит отредактировать файл /etc/acpi/eee.conf, конкретно, изменить значение переменной WIRELESS_MODULE и поставить её в ath_pci (в случае использования madwifi-hal) или ath5k (в случае использования стокового драйвера).

Теперь дело за малым. За менеджером соедененний.

Ноутбук устройство мобильное, и может использоваться в различных сетях, каждый раз править /etc/rc.conf и перезапускать сеть не выход. На помощь приходят менеджеры соединений. На себе проверил wicd, который есть в репозитариях ArchLinux. Прочитать про его настройку можно тут. Хотя я настроил методом «научного клика» и все заработало на ура :)

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

Проверил работу wifi совместно с wicd на работе - работает :) На этом тема wifi для меня пока закрыта.

// Asus EeePC 1000HA

На прошлой неделе пришел мне сабжевый нетбук. Машинка неплохая, мне, вцелом понравилась :)

В продаже, на момент покупки была только версия с WindowsXP SP3, которую по приходу снес и поставил туда ArchLinux.

При конфигурировании пользовался статьями а ArchWiki:

По результату, использую стоковое ядро, вайфай ещё не трогал, пока родной стоковый драйвер сетевой карточки (но уже сталкивался с ошибкой в назначении MAC адреса, так что нужно будет обновиться). Тачпад настроил пока по дефолту, настроил ACPI (из первой статьи для Eee PC 901), так что кнопочки все работают, suspend2ram работает тоже, звук изменяется и яркость тоже. Настроил cpufreq в целях экономии батареи. В общем ещё опишу что да как.

В планах: