NVidia GeForce GT440 в Debian Squeeze.

На той неделе поддался слабости и позволил себе небольшой апгрейд - прикупил Palit GeForce GT440 на замену своему старичку Palit GeForce 7300GT.

Драйвера которые сейчас предоставляет Debian Squeeze (195.36.31-6) не подходят для новой видеокарты, ее поддержка появилась начиная с версии 270.4106, которая вышла в апреле этого года.

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

Дистрибутивные пакеты не стали, пришлось сделать бэкпорт для squeeze. Собранные пакеты лежат в моем репозитарии в секции backports. Подключить в APT можно добавив в /etc/apt/sources.list

deb http://www.tataranovich.com/debian squeeze backports

После этого мне пришлось добавить репозитарий тестинга, чтобы стянуть недостающие зависимости и немного поиграться с apt pinning - соответствующий кусок моего /etc/apt/preferences

Package: * 
Pin: release a=testing 
Pin-Priority: -1 

Package: nvidia-support 
Pin: release a=testing 
Pin-Priority: 500 

Package: nvidia-installer-cleanup 
Pin: release a=testing 
Pin-Priority: 500 

Package: glx-alternative-nvidia 
Pin: release a=testing 
Pin-Priority: 500 

Package: glx-alternative-mesa 
Pin: release a=testing 
Pin-Priority: 500 

Package: glx-diversions 
Pin: release a=testing 
Pin-Priority: 500

На выходных выдалось время наконец поставить карточку и сделать пару тестов. Первое, что я проверил - была поддержка проигрывания видео через VDPAU. На старой при проигрывании 1080p нагрузка на двухядерный проц была больше 80-90%. После апгрейда нагрузка упала до 3-6%.

Разочарованием стала поддержка аппаратного ускорения в flash player. При проигрывании на полном экране изображение дрожало и шло с рывками. В дополнение к этому черные учатки в интерфейсе стали просвечивать картинку из flash проигрывателя. Проблема решилась отключением поддержки аппаратного ускорения.

Опакетил midnight commander.

Несмотря на то, что новая версия Midnight Commander'а (ChangeLog для версии 4.7.5.3) вышла больше двух недель назад, сопровождающий пакета в debian похоже потерял интерес или не имеет свободного времени. Сегодня я выкроил немного свободного времени и подготовил пакет для последней стабильной версии.

Стянуть пакеты для Lenny и Squeeze i386 можно в моем репозитарии.

Еще я решил накидать небольшую доку, как пересобрать пакет из моего репозитария под свой дистрибутив/архитектуру (актуально для debian-based дистрибутивов):

Добавляем мой ключ (необязательно, но будет ругаться на неизветную подпись)

$ wget -q -O- http://www.tataranovich.com/tataranovich.asc | sudo apt-key add -

Добавляем источник

$ echo 'deb-src http://www.tataranovich.com/debian squeeze main' | sudo tee -a /etc/apt/sources.list

Скачиваем исходники для версии 3:4.7.5.3-1 и зависимости для сборки

$ sudo apt-get update
$ sudo apt-get install build-essential fakeroot
$ apt-get source mc=3:4.7.5.3-1
$ sudo apt-get build-dep mc=3:4.7.5.3-1
$ cd mc-4.7.5.3/
$ dpkg-buildpackage -rfakeroot

Собранный пакет будет лежать уровнем выше.

Обновил пакеты для openbox

Собрал пакеты для openbox в вариантах Lenny (i386) и Squeeze (i386). Забрать можно в моем репозитарии.
Настройки APT можно посмотреть тут

Вышел новый openbox.

Недавно вышла новая версия openbox Сегодня дошли руки собрать пакет для Debian Squeeze. Заодно сделал реорганизацию своего репозитария.

Настройки репозитария:

Debian Squeeze

deb http://www.tataranovich.com/debian squeeze main
deb-src http://www.tataranovich.com/debian squeeze main

Debian Lenny

deb http://www.tataranovich.com/debian lenny main
deb-src http://www.tataranovich.com/debian lenny main

Чтение лога FTP - xferlog

Расшифровка FTP лога в формате xferlog

Сегодня пригодилось, чтобы быстро глянуть расшифровку.

Новые проблемы с hibernate на моем eeepc.

Я уже упоминал о проблемах в работе hibernate (он же suspend to disk) в одном из своих предыдущих постов. Тогда я откатил ядро и отправил баг, на большее времени не хватило.

Теперь я решил вернуться к проблеме, так как она получила новый виток. Началось с того, что после выхода из hibernate перестали запускаться приложения. В dmesg видно, что падения вызывает segfault. Причем падает не все подряд, а только часть.

May 13 07:16:25 dragoncore kernel: [ 4374.516022] egrep[10517]: segfault at 9eef73d ip 080510fa sp bfcd5a8c error 6 in egrep[8048000+18000]
May 18 07:22:56 dragoncore kernel: [10412.759167] urxvt[22902]: segfault at 42a648c8 ip b70e7020 sp bf95d2a0 error 6 in libperl.so.5.10.1[b70a9000+14a000]

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

sudo debsums | grep -v OK$

Таким образом ищутся файлы, контрольная сумма которых не совпадает с эталоном. Нашло несколько несовпадений

/usr/bin/dbus-daemon                      FAILED
/lib/libdbus-1.so.3.4.0                        FAILED
/usr/lib/libgobject-2.0.so.0.2400.2            FAILED
/bin/zsh4                                      FAILED

После перезарузки проверка была уже без ошибок.

Для чистоты эксперимента система была обновлена до актуального squeeze + ядро до 2.6.32-31. После как и полагается нетбук был перезагружен. Далее для выяснения причины попробовал запустить бесконечный цикл из связки hibernate и debsums. Чтобы не приходилось каждый раз включать ноутбук, я заменил в /etc/uswsusp.conf

shutdown method = platform

на

shutdown method = reboot

Теперь после засыпания на диск происходит перезагрузка, а не отключение питания. Для большей автоматизации был написан скрипт

#!/bin/bash

PREFIX=/var/log
COUNT=0

while true
do
dmesg -c > /dev/null
sync
pm-hibernate
let COUNT=${COUNT}+1
echo -e "DMESG\n\n*****\n\n" | tee ${PREFIX}/hibernate.${COUNT}.log
dmesg | tee -a ${PREFIX}/hibernate.${COUNT}.log
echo -e "\n\nDEBSUMS\n\n*****\n\n" | tee -a ${PREFIX}/hibernate.${COUNT}.log
debsums | tee -a ${PREFIX}/hibernate.${COUNT}.log | grep -v OK$
if [ $? == 0 ]; then
echo -e "\n\nDetected corruption!\n\n" | tee -a ${PREFIX}/hibernate.${COUNT}.log
dmesg | tee -a ${PREFIX}/hibernate.${COUNT}.log
sync
exit 1
fi
done

Скрипт выполнялся до тех пор, пока debsums не находил "поврежденные" файлы. Из двух прогонов за сегодня первая ошибка была на 14-й итерации, а второй раз нашло на 2-ой.
Пока я выкрутился через suspend-hybrid (благо новая батарея это позволяет). Завтра попробую тоже самое, но без использования KMS.

Отключение сбойного жесткого диска без остановки сервера

Придя сегодня на работу, обнаружил, что девелоперский сервер в глубокой "задумчивости". При попытке пинговать его выявилась значительная потеря пакетов. Через минуту смог залогиниться через SSH - сказывались потери пакетов. Первый делом на проблемной машинке глянул

# dmesg | tail
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete

Видимо один из 4-х дисков приказал долго жить и его срочно нужно отключить от RAID. Самое интересное, что за полтора часа, пока сервер загибался, сбойный винт не пометило как сбойный.
Чтобы извлечь нужный диск и потом отключить его физически нужно знать его S/N (у нас стоят 4 одинаковых WDC WD2502ABYS - поэтому просто по производителю глянуть не получится).
Пробую найти сбойный диск перебирая все винты на сервере

for hdd in sda sdb sdc sdd; do smartctl -d ata -a /dev/$hdd | grep ^194; done

Скрипт залипает на /dev/sdb, исключаю его из перебора и пробую вновь. На этот раз отрабатывает без ошибок.
Теперь остается выяснить его серийный номер (S/N):

# ls -l /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E8* |grep sdb$
lrwxrwxrwx 1 root root  9 Окт 25 10:39 /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E882772 -> ../../sdb

Получается что его S/N WCAT1E882772. Теперь извлекаем его из raid:

mdadm --manage /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1
mdadm --manage /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2

Остается остановить диск, чтобы система не пыталась его переинициализировать:

# ls -ld /sys/class/scsi_device/*/device/block:sdb
lrwxrwxrwx 1 root root 0 Янв 21 10:03 /sys/class/scsi_device/2:0:0:0/device/block:sdb -> ../../../../../../block/sdb

# echo 1 > /sys/class/scsi_device/2:0:0:0/device/delete

Проверяем, остановлен ли диск

# dmesg |tail

SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: disabled

Осталось вытащить его из сервера и сдать по гарантии =)