http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a9c85944427e3c4355bce67d7f6...

author   Alexander Strange
Thu, 2 Jun 2011 17:15:58

У кого cpu > 1 - проверьте, быстрее стал ?

Поставил вот ubuntu 10.04 на старый комп, ещё в AT-шном корпусе - cel-400Mhz/256Mb ram/10 GB hdd/TNT2 Vanta 8Mb.

Запускалось ОК.

Скомпилировал ядро 2.6.38 (с небольшой коррекцией для nouveau, на 8 мб дефолтный 1280x1024x32 фрэймбуффер съедал слишком много памяти - убавил для консоли глубину цвета до 8 бит) - пришлось добавлять параметр acpi=force в загрузчик.

Обновил libdrm/mesa/xf86-video-nouveau до версий из git (предварительно обновил X-овые пакеты до максимума, который был в https://launchpad.net/~xorg-edgers/+archive/ppa) . Обновил xserver до 1.9-branch (Сам скомпилял и забил поверх пакетного 1.8)

И вдруг понял, что у меня отвалился вентилятор на процессоре. Т.е. при старте машины он есть, а после запуска ядра - останавливается. С перегревом машины и её ребутом или подвисанием.

Ох, ши .... сказал я, полез в дебри /sys , нашёл там решение:

echo 1 > /sys/devices/LNXSYSTM\:00/subsystem/drivers/fan/PNP0C0B\:00/thermal_cooling/cur_state

Крутится теперь ....забил строчку в /etc/rc.local

Однако, Ubuntu не очень любит, когда я поверх работающих Х-ов начал новые ставить ... gdm перезапустился. Но в целом вроде работает, правда система уже слегка поломана моим checkinstall, нормальное заворачивание в deb со всеми зависимостями я пока не осилил.

Картинки оно не достойно, ибо дефолтный IceWM.

PS: а вот ещё ppa: https://launchpad.net/~lucid-bleed/+archive/ppa Всё-таки особо тяжелые пакеты лучше компилять на чём-нибуть побыстрее.

Я вот тут сижу и билдю .....

/mnt/test/deli-0.7.x-ports/ports/ap/sox/sox-12.17.9-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/rexima/rexima-1.4-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/ghostscript/ghostscript-7.07.1-i386-4.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/nano/nano-2.0.6-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/base/tcp_wrappers/tcp_wrappers-7.6-i386-7.tgz
/mnt/test/deli-0.7.x-ports/ports/devel/libtool/libtool-1.5.22-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/net/links2/links-2.1pre28-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/dillo/dillo-i18n-0.8.6-i386-4.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/dillo/dillo-i18n-0.8.6-i386-5.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/xchat/xchat-1.8.11-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/unrar/unrar-4.0.3-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/eject/eject-2.1.5-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/imagemagick/imagemagick-6.6.5-10-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/python/python-2.7.1-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/texinfo/texinfo-4.13a-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/apr/apr-1.4.2-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/neon/neon-0.29.5-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libpcre/libpcre-8.11-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/readline/readline-6.1.2-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libgmp/libgmp-5.0.1-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libmpfr/libmpfr-3.0.0-p8-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libmpc/libmpc-0.8.2-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/make/make-3.82-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/db/db-4.8.30-i386-1.tgz

И куда бы это всё залить, чтобы добро не пропадало? (всё под Deli 0.7.2)

Поиск по ЛОРу показал наличие тем с данной машиной , но вот этого кажется ещё не было:

http://www.phantom.sannata.ru/forum/index.php?t=4189&a=stdforum_view&o=&st=60

Один московский товарищ запустил на этой штуке портированный Linux 2.0.36

который (с сырцами) тут (до сих пор): http://ftp.stu.neva.ru/besta/linux-src/

в общем далее по ветке всплыла идея организовать сайт про этот самый (к сожалению, полностью на иностранных комплектующих, как выясняется) советский компьютер, где в качестве сервера будет одна из двух «Бест». Может кто-то с ЛОРа (Мск) захочет заглянуть на огонёк к ретрокомпютерщикам? А предполагаемому положительному результату мы все порадуемся... Кстати, в недрах staging насколько помню как раз есть (пилится) поддержка шины VME, может действительно кто-то на 2.6 портирует все наработки? Особенно весело было бы fb драйвер сделать, описание программирования видеоконтроллера (даже двух) вроде бы есть ....

Решил вот запостить скриншот своей «новой» четвёрочки, которая на удивление неплохо справилась с компиляцией браузера из набора портов для Deli Linux 0.7.2 (dillo-i18n-0.8.6-i386-4). ЛОР слегка непрвычный в 640x480x256 , но читать можно. А вот как поместить картинку - загадка (для меня). Сейчас соберём links2, может оттуда получится (огнелис на 16 мб оперативы - это ОЧЕНЬ медленно)

http://lkml.org/lkml/2010/11/12/344

Насколько я понял, эта версия не самая оптимальная, но скорость чтения поднимает в 1.4 раза на четырёхядерном процессоре, скорость записи - до 2-х с лишним раз быстрее. Поддерживаются шифрованные разделы поверх шифрованных разделов. Да, тест в сообщении был с CFQ, говорят для dm-crypt сейчас это не самый оптимальный шедулер ввода-вывода.

Что-то не везёт мне с udev-ом. Собрал самую новую версию, из git (http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=560de575148b7efda3... - Use ata_id, not scsi_id, on ATAPI devices), через немного подпиленный SlackBuild - всё равно при старте не было правильной группы на /dev/hda (cd-dvd-rw привод). Путём манипуляций с копированием 50-udev-default.rules, 60-cdrom_id.rules в /etc/udev/rules.d и псоледующим редактированием на предмет замены sr* на hd* там где было что-то про cdrom, плюс добавил в 50-udev-default.rules ATTRS{media}==«cdrom» в соответствующее правило:

--- /lib/udev/rules.d/50-udev-default.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/50-udev-default.rules 2010-11-06 02:42:53.000000000 +0300
@@ -75,7 +75,7 @@
SUBSYSTEM==«block», KERNEL==«fd[0-9]», GROUP=«floppy»

# cdrom
-SUBSYSTEM==«block», KERNEL==«sr[0-9]*», SYMLINK+=«scd%n», GROUP=«cdrom»
+SUBSYSTEM==«ide», KERNEL==«hd[0-9]*», ATTRS{media}==«cdrom», SYMLINK+=«cdrom%n», GROUP=«cdrom»
SUBSYSTEM==«scsi_generic», SUBSYSTEMS==«scsi», ATTRS{type}==«4|5», GROUP=«cdrom»
KERNEL==«pktcdvd[0-9]*», GROUP=«cdrom»
KERNEL==«pktcdvd», GROUP=«cdrom»


--- /lib/udev/rules.d/60-cdrom_id.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/60-cdrom_id.rules 2010-11-06 02:04:21.000000000 +0300
@@ -2,10 +2,10 @@

ACTION==«remove», GOTO=«cdrom_end»
SUBSYSTEM!=«block», GOTO=«cdrom_end»
-KERNEL!=«sr[0-9]*|xvd*», GOTO=«cdrom_end»
+KERNEL!=«hd*|xvd*», GOTO=«cdrom_end»
ENV{DEVTYPE}!=«disk», GOTO=«cdrom_end»

-KERNEL==«sr[0-9]*», ENV{ID_CDROM}=«1»
+KERNEL==«hd*», ENV{ID_CDROM}=«1»
IMPORT{program}=«cdrom_id --export $tempnode»

LABEL=«cdrom_end»


Но после этого /etc/rc.d/rc.udev reload не помогло, а вот после запуска udevadm test /devices/pci0000:00/0000:00:11.1/ide0/0.0/block/hda (путь был найден запуском udevadm info -q path -n /dev/hda) всё нужные симлинки появились, группа для /dev/hda - «cdrom», не дефолтный «disk». Соответственно k3b работает.


Кто-нибудь может проверить, дефолтный udev-164 (или лучше - git-версия) на ядре с old deprecated ATA drivers тоже имеет косяки с ide cd-rom/rw ?

http://blog.martin-graesslin.com/blog/2010/10/optimization-in-kwin-4-6/

Обещают ускорение работы фильтра Lanczos, который сильно усложняет жизнь пользователям в 4.5 (фильтр не будет фильтровать все окна на экране, а только те, которые нужно). Обещают ускорение работы этой прыгающей анимации «приложение сейчас, вот-вот, ещё-чуть-чуть, запусти-и-ится». (которая с какого-то перепугу раньше превращалась в RGB окно без альфа-канала). Из общего есть (ну, или должно быть в trunk) кэширование текстур и геометрических данных, использование TFP (texture-from-pixmap, блин, а раньше-то они через что делали?! ЭТо TFP уже четыре года как известно .....) что должно избавить от медленных преобразований между QPixmap/QImage. Эффекты трансформации _одного_ окна вызывали перерисовку _всего_ экрана. Должно быть «фиксед», в новой версии. Правда, все плагины придется переделать, один за одним, чтобы получить желаемый эффект.

Тема «ускорить blur-эффект» оставлена примерно до 4.7

Итак, продолжая злостные эксперименты, собрал udev-153 с патчем

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=665ee17def2caa6811...

«udevd: always try to find an idle worker instead of forking a new one»

(на новый удав - новые грабли наступать пока не охота)

Но это не помогло - на моём достаточно модульном конфиге сразу после старта udev всё замирает, с mem=32m. С mem=36m - идет до текстового логина, как и положено. Workaround с ранним подключением физического своп-файла не очень хочу использовать, ибо тормоза, а виртуально-сжатый через zram не очень-то и помогает, на таких малых объемах памяти. Отсюда вопрос: а что делает ваша система, если попытаться её загрузить с такими же параметрами: mem=32m ?

Может у кого из местных пользователей radeon проблема вылезала, в баге обсуждают подвисания машины в как-бы случайном порядке, в ходе нормальной деятельности (firefox там. .... ).

Кажется, в логике работы с чипами, где vram < pci bar size была ошибка, приводящая к этим подвисаниям. У меня карточка с такими же параметрами (64 vram, 128 PCI BAR) - но вроде особых подвисаний за пару дней не видел. Кто хочет - может потестить последний патч, https://bugs.freedesktop.org/attachment.cgi?id=39651 а я пока подумаю, как бы подвесить свою машину, м.б. agpmode=-1 поможет.

http://www.liveinternet.ru/users/ilya_chernykh/post129345101/

Выглядит оно конечно хорошо, но есть вопросы:

1. Оно же на qt2. Патчи по безопасности на это вроде уже никто не делает, как и на сам KDE2 ?

2. Управление оборудованием: xrandr 1.2, энергосбережение, управление частотой процессора .... ? Из GUI, имеется в виду. Кто-то эту функциональность добавляет, как для Trinity ?

3. Автоопределение подключаемых устройств, удобное задание опций монтирования? (на КДЕ3 на это дело патч был, не принятый в свое время в основную ветку. Ибо слишком много элементов управления добавлял, для stable это считалось неприемлемо.)

4. Эпичные баги ? :}

После собственноручного обрушения бОльшей часть КДЕ-шных прог - пересобрал их заново на своей (почти) -current Slackware.

Среди прочего был k3b 1.0.5

Он с некоторых пор повадился подвисать при проверке DVD проекта. Вот баг. http://bugs.kde.org/156684

В нём , в комментарии 30 есть патч. Но я его не использовал, а использовал другой, отсюда:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-cdr/k3b/files/?hi...

k3b-1.0.5-eject_186173.patch

Вроде бы маленький проект записал и проверил нормально. Если кто-то ещё использует старый k3b для KDE3 - отпишитесь, какой из патчей у вас работает лучше?

Там ffmpeg патчи ещё есть, для них я запускал autoconf, а для нового autoconf-2.64+ оказывается нужен патч, примерно как тут:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=16635&group_id=4482

http://git.altlinux.org/people/drool/packages/?p=sim.git;a=blob;f=sim-0.9.5-f...

На самом деле сейчас этот патч уже в svn репозитарии sim-im (я побаивался оттуда обновляться - но там к счастью оставили старый код для КДЕ3, не выкорчёвывая его поддержку, а всё новое переехало куда-то на mercurial )

ПС: придётся-таки через какое-то время переезжать на КДЕ4 проги, сам-то кде3 в виде ТДЕ продолжает развитие, как я смотрю, но вот все дополнительные внешние проги (k3b, digikam, нелинейный видеоредактор ) - всё уехало на qt4/kdelibs4 :/ А оно и места ест больше, и компилируется дольше, и внешний вид не в моём вкусе, по крайней мере дефолтный.

Поставил я себе во флаги --param ggc-min-expand=0 --param ggc-min-heapsize=8192 , и пересобираю gentoo system потихоньку, почти 4 дня.

И тут на libxml2 смотрю - cc1 аж 150 минут (!) думал над файлом. Посмотрел размер файла - 800 кб. Восьмьсот килобайт. Сишного кода с комментариями. И он там не один такой. Пожалуй, ggc-min-heapsize надо было побольше поставить..... Зато даже под конец компиляции virt для cc1 не вылез за пределы 30 Мб, а res - за 24 мб.

Но - 800+ килобайт КОДА .... я просто сражён на повал. Даже в ffmpeg такого безобразия нету:

du -h source/mplayer/ffmpeg/libavcodec/dsputil.c
164K source/mplayer/ffmpeg/libavcodec/dsputil.c


du -h source/mplayer/ffmpeg/libavcodec/mpegvideo_enc.c
144K source/mplayer/ffmpeg/libavcodec/mpegvideo_enc.c

А это чудо ...
http://svn.gnome.org/viewvc/libxml2/trunk/xmlschemas.c?view=log
File length: 816925 byte(s)

Будет кстати забавно, если portage отфильтрует эти параметры для того компонента, которому они предназначались : gсc и его жадному до памяти genattrtab.

Да, компилится оно на mips r5k, 180 Mhz. На виртуальных хостингах (откуда ноги у конкретных значений и растут, как я понял) наверное всё гораздо быстрее.

В общем, если и сам gcc параметры эти использует при своей компиляции - это будет очень здорово, значит даже относительно слабая машина (по всем параметрам сразу - ЦПУ, память, диск) как минимум в состоянии скомпилировать даже большой С проект. Я уж опасался, что на 64 Мб gcc4 вообще не жилец. Оказалось, его просто подтюнить надо. Хотя наверняка узнаем только завтра.

Решил недели две назад обновить систему на своей SGI O2 (mips). Сказано - поехали! Поскольку машина по скорости компиляции в 6 примерно раз медленее моего десктопа (на котором Slackware), а он в свою очередь примерно в 8 раз медленее среднего прошлогоднего AMD Barton 2300BE (кажется так, уж не помню точно, друг давал машину на время) - то просто «пересобрать всё» выглядело ну очень утомительным процессом. Решил обновлять пакеты по-одному, или небольшими группами. Успешно обновил gcc до 4.4.4 (почти словив OOM, сейчас почитал http://hostingfu.com/article/compiling-with-gcc-on-low-memory-vps , добавил эти параметры, ещё раньше убрал -pipe из CFLAGS). Успешно обновил большую часть media-libs, скомпилировал audacious и GIMP-2.6.10 (размаскировав оба). Audacious играет, правда процентов 40-45 от mips r5k/180Mhz/512K L2 ест. ладно, поставлен был «для красоты» (ну и посмотреть, соберётся ли). ГИМП оказался тоже достаточно рабочим для создания скриншота, как минимум (http://img196.imageshack.us/img196/8307/gimp2610mips1.jpg). Правда, для него пришлось пересобрать pygtk/pyobject , а для них - numpy (от количества warnings в котором мой экран скроллился несколько раз, при emerge предупреждения фиксируются и потом отдельно выдаются на экран, мол не приставайте к нам с багами, бегом на страницу проекта, который так код пишет.).

И всё было хорошо, пока я не стал пересобирать gtk+ . Оно вывалилось с ошибкой, оказалось при апгрейде libpng 1.2 -> 1.4 я забыл запустить прилагаемый скрипт, который в свою очередь хотел portage-utils, которые пришлось поставить. В общем странное осталось ощущение - простейшие операции _специально_ не автоматизируются, видимо чтобы админ не спал, а читал что ему пишут на экране. Ладно, обновил gtk - обновлю и X сервер! Обновил ... правда, несмотря на обычную тщательность (просмотр вывода emerge -p , установка USE флагов по необходимости) пропустил казалось бы безобидное обновление udev. X-то запустились, правда конфиг был не тот немного, и они проигнорировали «устаревшие» драйвера kbd/mouse. ладно, ребут .... И тут отваливается udev. Не очень страшно, если грузишься по сети, и вся система - на NFS. Нашёл казалось бы решение - нужно пересобрать glibc с новыми kernel-headers (2.6.35 поставил, вместо старых 2.6.24). Стал пересобирать ... Правда, меня предупредили на #gentoo-mips, что апгрейд до 2.11.2 может вылиться в сегфолт. Ну, я сделал quickpkg для текущей glibc, и полный бэкап всего, что было на NFS root.

Обновив glibc - нарвался на сегфолты, почти всего, начиная от gawk и заканчивая gcc. Обидно, но emerge работает. Указываю ему на /usr/portage/packages/sys-libs/glibc-версия.tbz2 - ругается что «install by path is broken!» а потом вообще отказывается делать downgrade! (т.е. вернуться на старую версию glibc). Пришлось делать emerge --unmerge glibc (оно оказалось даже не в защищенных), потом tar'ом распаковывать архив-пакет со старой glibc, и водворять её на место (это на NFS сервере). Гружусь, emerge работает, предлагает поставить glibc. Умно. Маскирую новую версию glibc, заодно с udev-162. На этапе компиляции выясняется, что куда-то потерялся /usr/lib/crt1.o Ого. Достаю его из полного бэкапа (который на x86 машине, в виде squashfs4-образа, который достаточно смонтировать). После полусуток компиляции (из которых часа 2 генерились локали - надо бы это поправить ....) кажется получил рабочую glibc-2.9

Стал пересобирать систему. Но сначала пришлось мигрировать на openrc. А для этого пришлось пересмотреть кучу файликов (сорок), которые etc-update посчитал устаревшими. В большинстве случаев их можно было спокойно заменить, устаревший вариант на новый. В двух случая оставил старые настройки. Наверное, такая пляска была бы в любом дистре, захоти я его после почти полугода простоя обновить.

Openrc на этой медленной машине действительно грузит систему заметно быстрее, но не уверен что произойдёт, если он отвалится, по какой-то причине (glibc опять ....). Всё-таки поддержание gentoo в рабочей форме требует усилий, на быстрой машине это не так заметно, а тут .... две недели и всё ещё не обновился толком. Правда, и засады с glibc на x86 как я понимаю нет, да и на mips она не везде проявляется.

https://bugs.gentoo.org/show_bug.cgi?id=340243 - в эту багу мне предлагали отписаться, но я пока дождусь результатов emerge system, для glibc-2.9 А потом можно ещё один образ сделать, и экспериментировать с glibc-2.11

В общем хорошо конечно, что хоть один дистрибутив поддерживает старые SGI машины. И хорошо что системный компилятор до сих пор компилирует себя на 256 мегабайтах оперативки без свопа. Но всё же я всерьез начал думать о distcc .....

Эх, знатные флеймогоны там собрались, не хуже чем тут.

Однако среди флейма попался забавный результат - у кого-то OpenArena выдает под 100 fps на открытом r600c драйвере, в разрешении 2560*1600 (!)

-----
http://www.phoronix.com/forums/showpost.php?p=151088&postcount=132

А ниже - ещё более снногсшибательный результат - почти 200 fps в 1680x1050!

http://www.phoronix.com/forums/showpost.php?p=151133&postcount=136

Причем в последнем тесте именно r600g выигрывает, хоть и немного, у «классики».

Это все с патчем для отключения vsync в 2D драйвере и последний результат с включением 2d tiling (отключен в коде по-умолчанию, артефакты на _некоторых_ карточках).


200 фпс - это уже некоторый запас мощности для AA (которого пока нет, но как будет - сразу своё отгрызёт).


Но история (git history) показывает, что буквально несколько коммитов могут изменить ситуацию с «одна десятая скорости старого драйвера» до «превосходит по скорости старый драйвер». Причём ситуация зависит от того, встроенная карточка или нет (буфер с данными из дискретной видеопамяти читается на топовых и даже средних картах намного быстрее, чем из системной по PCI-E, пропускная способность памяти там пиковая до 130 Гб/С, но даже более умеренные 56-64 гб/c куда больше, чем на интегрированно видео, шарящем системную память.)

Поэтому мораль проста: прежде чем сказать «тормозит!» - не забудь обновиться .....

Г. Мильке. Путь в космос. Проблемы полёта в мировое пространство.
Перевод с немецкого Е.Н. Греченко, И.А. Крупенниковой, В.Ф. Прохорова.

Под редакцией И.М. Ильичевой.

Из-во иностранной литературы, Москва, 1959.

---------------------

Книга простенькая, «без формул». Но илл. в наличии.

http://foto.mail.ru/mail/randrik/71/ - маленькая часть указанных иллюстраций.

SWrast, даже не llvmpipe!

http://img62.imageshack.us/i/swrastberyltfp.jpg/



guest@slax:~$ glxgears
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Duron(tm) Processor
Mesa: Mesa 7.9-devel DEBUG build Jun 13 2010 04:24:04
Mesa warning: software DXTn compression/decompression available
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
149 frames in 5.0 seconds = 29.766 FPS

Так что не-тормозящая на vesa mac OS X почти побеждена, осталось найти почему не работает emerald, как можно заметить декораций окон нет.

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

http://www.phoronix.com/forums/showpost.php?p=130837&postcount=74

https://bugzilla.kernel.org/show_bug.cgi?id=12309

Копирую сюда свой setup

0. Model=ST3160021A системный + Model=SAMSUNG SP0802N дополнительный
1. «старом» ide 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06),
2. без эмуляции (НЕ через libata),
3. драйвер вбит в ядро,
4. 250 hz таймер,
5. без preempt,
6. проблем с прерываниями (irq storm) нету,
7. процессор старый одноядерный K7 (нет изменения частоты),
8. памяти 768 Мб, но можно сделать сколько надо.
9. FS: ext3 mode=ordered + XFS
10. CFQ везде.
11. ванильное 2.6.34-rc5

http://forums.ps2dev.org/viewtopic.php?t=10156&postdays=0&postorder=asc&start...

http://sourceforge.net/projects/kernelloader/files/ (235.5 MB)

Говорят, должно работать без modchip-а. (но есть странные проблемы с X-ами, неправельный modeline?).

http://kernelloader.cvs.sourceforge.net/viewvc/kernelloader/BlackRhino/src/x/... - вот