Toshiba Satellite A100-811: Ubuntu

Вот уже что-то около полтора месяца, как мой Toshiba Satellite A100-811 работает под Ubuntu Linux 6.10 (Edgy Eft). Всё началось с того, что мне надоело тянуть бэкпорты для Sarge и собирать софт, которого не было ни в репозитории, ни на бэкпортах вручную. Тем более, некоторые вещи, как например xorg собирать и ставить вручную было и вовсе неохота (заметный framedrop в mplayer'е, работающем через vesa, тоже порядком надоел). Нового Etch тогда под рукой у меня ещё не было, зато пришёл почтой заказанный на ubuntu.com Edgy Eft. Итак, решив, что в конце концов пролетариату нечего терять кроме своих цепей, я потёр систему, оставив снапшот /etc и домашний директорий. Надо сказать, что инсталлятор Ubuntu оказался очень симпатичным. Установка прошла без проблем. Т.к. версия для AMD64/EMT64 почему-то не хотела ставиться нормально, то я использовал обычный дистр для i386. Первое впечатление оказалось несколько неожиданным. С одной стороны, практически всё (за исключением злополучного bluetooth и модема, который я, правда, и не пытался использовать) работало из коробки. Даже Intel PRO/Wireless 3945ABG на драйвере ipw3945, о котором я здесь также уже упоминал. Но, Gnome в качестве десктоп-менеджера не сильно меня воодушевлял, а boot-сплэш вместо дампа ядра несколько дезориентировал :-). И с первым, и со вторым я справился. Gnome заменил на KDE, а к boot-сплэшу просто привык уже :-) Из коробки на штатном ядре (2.6.17) у меня работали даже suspend-to-ram и hibernate. Но, когда я налюбовавшись всеми этими прелестями начал окультуривать свежеустановленную систему, начали проявляться и побочные эффекты. 1-й и самый заментый - практически все пакеты надо тянуть из репозитория в сети, т.к. у меня был лишь установочный диск с базовыми компонентами (естественно, ядро, libc, xorg, Gnome, base-utils, net-utils и всё, по существу). Поэтому для людей, у которых нет толстого канала это может очень сильно омрачить первое впечатление. У меня толстого канала тоже нет, но зато есть работа, где, в свою очередь, есть приличный канал :-) Второй момент, вся система изначально заточена под Gnome в качестве десктоп-менеджера и это быстро проявляется не очень приятным образом. Так, например, после установки KDE у меня отказался нормально работать hibernate и suspend-to-ram. Система засыпала, но уже не просыпалась. Самое смешное, что происходило такое безобразие только при работе в KDE и никак не отражалось на gdm (я оставил его логин-менеджером - внешне он понравился мне больше, чем kdm). Немного порыскав по логам и конфигам я сделал такие правки в /etc/hibernate/common.conf:

### clock
SaveClock restore-only

### network
DownInterfaces eth0 eth1
UpInterfaces eth0 eth1

### vbetool
EnableVbetool yes
RestoreVbeStateFrom /var/lib/vbetool/vbestate
VbetoolPost yes
RestoreVCSAData yes

### xhacks
SwitchToTextMode yes
# UseDummyXServer yes
# DummyXServerConfig xorg-dummy.conf

### xstatus
## This can be set to gnome, kde or x:
XStatus kde

и такую в xorg.conf:

Section "Device"
 Identifier "Intel Corporation Mobile Integrated Graphics Controller"
 Driver  "i810"
 BusID  "PCI:0:2:0"
 Option  "VBERestore"  "true"
EndSection

(добавил опцию "VbeRestore" - для использования этого добра необходим пакет vbetool). Вот, собственно, и всё, что я сделал для восстановления работоспособности режимов hibernate и suspend-to-ram.

Ещё один неприятный момент выявился позже. Об этой ошибке уже писали на форуме ubuntu. При возврате из спящего режима, во время работы от аккумулятора, только одно ядро CPU работает на пониженной частоте, в то время, как другое процессорное ядро работает на полных оборотах, что нежелательно при работе от аккумулятора и вообще нарушает системную гармонию :-) Я быстро нашёл чьё-то решение: поместить следующий скрипт в /etc/acpi/resume.d

#!/bin/sh

SYS_DIR=/sys/devices/system/cpu
POLICY=ondemand

for CPU in `ls $SYS_DIR`
do
    echo -n "$POLICY" > $SYS_DIR/$CPU/cpufreq/scaling_governor
done

под именем, ну пусть хотя бы и 10-dualcore-freq (я обозвал его так, хотя у автора он назывался по-другому). Однако, это мне не помогло. Как было видно из лога /var/log/acpid, он почему-то не обрабатывал такие события, как suspend или resume. Зато он всё равно при пробуждении обрабатывал power, при котором, в свою очередь, выполнял скрипты из battery.d или ac.d, в зависимости от того, работает лаптоп от аккумулятора или сети. Поэтому сей скрипт я положил в /etc/acpi/battery.d, придя к выводу, что так даже лучше, потому что мне ни к чему экономить гигагерцы при работе от сетевого адаптера. Здесь, как не трудно догадаться по аналогии с boot-скриптами, префикс в имени файла "10-" - это приоритет. У меня, к примеру, этот скрипт имеет наивысший приоритет и выполняется самым первым.

Затем обнаружились проблемы с кард-ридером MMC/SD от Texas Instruments. Драйвер ядра просто не умел работать с некоторыми картами. Наконец я созрел для замены ядра! Я хотел заменить ядро в надежде, что новый драйвер, быть может, доработан в этом плане. Кроме того, я никогда не любил тайм-принты printk() :-) Итак, я решил поставить последнее ядро стабильной ветки, тарбол которого у меня было на тот момент - 2.6.20. Правда, я решился на замену ядра не сразу. Ведь драйвер для Intel PRO/Wireless 3945ABG тоже пришлось бы пересобирать. Но, в конце концов, я решился. Предвижу гневные возгласы, потому сразу скажу, там где мне проще работать по привычке, а не по-новому, я отдаю предпочтение привычке. У меня нет особого желания разучивать опции нового тула только потому, что его использование - это Debian-way. Поэтому, ядро я ставил вручную, как привык делать уже очень давно - без использования kernel-package:

cp /boot/config-<old-kernel-version> /usr/src/linux-2.6.20/.config
make oldconfig
make menuconfig
make -j 8 bzImage modules
make modules_install
update-initramfs -k 2.6.20 -c
cp ./System.map /boot/System.map-2.6.20
cp ./.config /boot/config-2.6.20
cp ./arch/i386/boot/bzImage /boot/vmlinuz-2.6.20

Правим /boot/grub/menu.lst соответственно - вот и вся премудрость. Затем, распаковав тарбол с модулем ipw3945 я попытался его собрать. Но... натолкнулся на глухое непонимание Makefile'а. Он кричал, что версия модулей подсистемы ieee80211 не соответствует карте символов ядра. Т.е., Makefile полагал, что я использую out-of-tree реализацию ieee80211, а не родную ядерную. Мне так и не удалось переубедить make. В сети я нашёл замечательное решение: пропатчить ядро на предмет ipw3945! Патч ipw3945-1.2.0_for_2.6.19.patch лёг на ядро без проблем. Правда, мне пришлось переконфигурировать ядро и пересобрать его, но зато - больше никаких проблем с компиляцией модуля вне дерева кода ядра. Ещё одна маленькая хитрость. Демон и микрокод для драйвера я не ставил - они уже были в системе. Но для того, чтобы всё заработало, надо сделать симлинк на демон ipw3945d-<old-kernel-version>, где бы вместо <old-kernel-version> стояла версия Вашего ядра (в моём случае, это 2.6.20, как не трудно догадаться :-) Кстати, в листинге ключ make -j определяет число параллельно выполняющихся экземпляров make при сборке. Если числовой параметр опущен, то make создаёт столько экземпляров самой себя, что в конце концов истощает все системные ресурсы. 8 - параллельных инстанций для моего Core 2 Duo было самое то. Если установить слишком большое число, система может перестать реагировать, будто она зависла, или начать сильно тормозить. Поэтому применяйте данный параметр разумно и без фанатизма. Кроме таймингов printk я убрал все ненужные модули, включил оптимизацию под Core 2 и включил в ядро драйвер консольного фрейм-буфера и vesa. Хотя, сперва я пытался заставить работать нативный драйвер intelfb. Драйвер имеет статус экспериментального и у меня так и не заработал нормально, поэтому я откатился к vesafb. Вот по сути и всё, что касается ядра.

Кстати, я долго пытался найти в KDE что-нибудь, что позволяло бы быстро переключаться между настройками сетевого интерфейса (домашняя сеть и сеть на работе), но так и не нашёл ничего работающего :-) В конечном счёте я решил воспользоваться способом, который видел когда-то в сети.

Суть этого нехитрого способа состоит в использовании разных схем в /etc/network/interfaces. Для его использования вносим изменения в сам файл /etc/network/interfaces:

auto lo
allow-hotplug eth1
iface lo inet loopback

mapping eth0
script /etc/network/map-scheme.sh
map home eth0-home
map work eth0-work

iface eth0-home inet static
 address xxx.xxx.xxx.xxx
 netmask xxx.xxx.xxx.xxx
 broadcast xxx.xxx.xxx.xxx
 network xxx.xx.xx.xxx
 gateway xxx.xxx.xxx.xxx

iface eth0-work inet static
 address yyy.yyy.yyy.yyy
 netmask yyy.yyy.yyy.yyy
 gateway yyy.yyy.yyy.yyy

auto eth0

Теперь мы имеем две схемы с разными настройками сетевого интерфейса: home - для домашней сети и work - для рабочей, соответственно. Там же, в /etc/network добавляем такой скрипт:

#!/bin/sh

iface="$1"
if [ "$iface" = "" ]; then iface="eth0"; fi
if [ -f /etc/network/scheme ]; then
 scheme=$(cat /etc/network/scheme)
 echo $iface-$scheme
else
 echo $iface
fi
exit 0

А в /usr/local/bin создаём такой скриптик:

#!/bin/sh

if [ $# -le 0 ]; then
 echo -n "Current scheme: "
 cat /etc/network/scheme
 exit 0
fi
echo "$1" > /etc/network/scheme

который у нас и будет переключать схемы и по совместительству показывать, какая схема активна в данный момент. Посмотреть её можно также в файле /etc/network/scheme, который используется нашим скриптом map-scheme.sh для получения имени активной схемы. Сама схема устанавливается скриптом netscheme. Опциональный параметр - имя схемы, на которую необходимо переключиться. Без параметра скрипт просто выдаёт имя активной схемы. После переключения схемы нужно ещё выполнить ifdown/ifup, чтобы изменение параметров вступили в силу.

Ну, что тут, в общем, скажешь, старый добрый shell script попрежнему даёт... эээ, фору разным там гуям ;-) Хотя, желающие вполне могут прикрутить к этому делу гуёвый фронт-энд, благо сделать это также не сложно.

В итоге, Edgy Eft мне понравилась. Я настроил под себя всё окружение. Свежий софт работает без нареканий. Хотя, кое-чего в репозитории не было и мне пришлось поставить недостающий софт из собственных запасов. Речь об Adobe Acrobat Reader и rar. Дистрибутивный KchmViewer меня приятно порадовал. Управление энергосбережением я настроил через KLaptop. К слову, влияние xfs на работу suspend установить больше не было возможности, так как я слегка реструктурировал разбиение диска. Теперь корневая ФС у меня на reiserfs, а /home - полностью на xfs. Я не вдавался в детальные исследования, но во всяком случае, ничто не мешает отмонтировать /home перед засыпанием и модуль xfs тут уже не может помешать, т.к. оказывается незадействованным. Действительно ли hibernate отмонтрирует /home, я не проверял - повторюсь ещё раз. Но, вполне вероятно, что проблему можно устранить, если использовать для root какую-нибудь другую ФС, кроме xfs. Драйвер i810 в xorg 7.1.1, как и ожидалось, прекрасно позволяет смотреть фильмы в полноэкранном режиме и играть в Quake III Arena. Правда, мне до сих пор не удалось заставить Q3A правильно масштабироваться. Но это уже мелочи :-)