Да уж... Долго ж вы все ждали...

vo blya ... terpenie Linusa okonchilos' ... tak chto 2.4.0 gluk polniy?

Не совсем в тему, но...
IMHO у меня загрузка CPU при переходе с 2.2.16 к 2.2.18 возросла процентов на 10%-20%.
Такие пироги...

А перейти из серии 2.2 на 2.4 безболезненно можно? По слухам надо покопаться, а где и как?

Кто-нибудь может объяснить в кратце основную прелесть от перехода на эту ветку с насижанного 2.2.18. Короче в чем основная крутизна? Что-то я толком тут нигде не прочитал. В основном одни перепалки были :-(

Кто нибудь качал ? Там поддержка ReiserFS есть ?

А netfilter/Makefile так и не исправили :( у меня с gcc-2.95.2 и glibc-2.2
не хочет компилиться...
---CUT---
make[2]: Leaving directory /usr/src/linux/net/ipv4'
make -C ipv4/netfilter
make[2]: Entering directory /usr/src/linux/net/ipv4/netfilter'
make all_targets
make[3]: Entering directory /usr/src/linux/net/ipv4/netfilter'
ld -m elf_i386 -r -o ip_conntrack.o ip_conntrack_standalone.o
ip_conntrack_core.o ip_conntrack_proto_generic.o ip_conntrack_proto_tcp.o
ip_conntrack_proto_udp.o ip_conntrack_proto_icmp.o
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686    -c -o ip_nat_ftp.o ip_nat_ftp.c
ip_nat_ftp.c: In functionelp':
ip_nat_ftp.c:315: structure has no member named ^Nat'
make[3]: *** [ip_nat_ftp.o] Error 1
make[3]: Leaving directory /usr/src/linux/net/ipv4/netfilter'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory /usr/src/linux/net/ipv4/netfilter'
make[1]: *** [_subdir_ipv4/netfilter] Error 2
make[1]: Leaving directory /usr/src/linux/net'
make: *** [_dir_net] Error 2
---CUT---                                                                       
буду исправлять мейкфайл и слать багрепорт....

Narod a pravda podskazhite cho nado updatit' na RH6.2 chtob entu vesh skompilirovat'

я где прочитал что самое быстрое ядро это было 2.2.5 например почему бы я перешел на 2.4 так как по слухам там поддержка SMP получьше. Ну и улучьшена поддержка многих устройств и есть подержка Itanium ;)

Хе, я давно уже на 2.4-test-ах сижу, жизнь заставила. :) У меня на серии 2.2 UDMA66 контроллер не хотит работать. Там весь прикол в том, что ветка 2.4 рассчитана на свежее железо последних двух лет, в отличии от ветки 2.2... Вообщем все новые процы поддерживаются, UDMA66 на нескольких контроллерах, ACPI, ну и все прочее. Настройки лучше структурированы, да и больше их по сравнению с 2.2. Из глюков помню у меня на ядре 2.4-test6 линух подох однажды. Выключил его нормально, включил, смотрю, а на диске вместо главного раздела под ext2 руины :(( пришлось переставлять. Хрен его знает, чего это было. Еще SCSI emulation так толком и не работает (на 2.4-test11), магнитооптика от Fujitsu IDE-шная со сказевым драйвером подрубается, по директориям хожу, файлы пишу, при попытке чтения того, mc отваливается и кернел мессагу страшную выдает про null pointer-ы вроде... на ядрах 2.2.x все в порядке. Да, еще один момент сексуальный :) - после перехода на ядро 2.4 возможено звук прийдется заново настраивать, у кого карточка ISA-шная, так же как и обычно (у меня это случалось, когда стояла ess1869). C PCI-ными такое вроде не требуется.

Ну у ROMUL-а базар кривой :))

Ждем дистрибутива Slakware 8.0 or RedHat 8.0, а еще лучше 8.2 и тогда качаем !

Ну наконец-то! 2.4 не то чтобы "глюк полный", но вылизывать его долго будут... :)

Esli jdat RedHat 8.0 (ili 8.2), togda i kachat` nado yadro => 2.4.5 [StS]

Debian 2.2: при переходе с 2.2.18 всё заметно быстрее стало. Ура Товарищи!

reiserfs годится от test12 - 3.6.23

Ну, подожду, пока supermount появится, ReiserFS подгонят к новым "фичам" ввода-вывода в 2.4, народ шишек понабивает, glibc адаптируется.
В общем, обязательно перейду на 2.4.2

Переход несложный, если дистрибутив достаточно свеж. Например, для Slackware-7.1
требуется обновить только util-linux, modutils и pppd или взять из current.
Работает все нормально. Сейчас готовлю серверок с новым ядром. Пока глюков никаких
не вижу.

У меня netfilter чисто собирается. Даю кусок конфига. В таком исполнении все работает.

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set

2AIS: в gcc diagnostics какая-то фигня у тебя - может камень у тебя разогнанный или память гнилая? Наверно еща раз компилять пустить надо. > ip_nat_ftp.c: In functionelp': > ip_nat_ftp.c:315: structure has no member named ^Nat'

На зеркалах уже есть ядро?
Кто пробовал?
А то на ftp.kernel.org забито все :-(

Утром спокойно скачал с ftp.fi.kernel.org,
встало легко. Прикрутил reiserfs. Проблем нет.

все почему-то забывают, что есть ftp.ru.kernel.org ;)

Наконец то появился USB драйвер для моей последней железки которую
незнал Линукс, из-за которой нужно было грузиться в маздай, что бы
перелить данные принесенные с работы домой, это USB-IDE бридж от In-System Design(ISD) + HDD.... Вообщем, драйвер появился раньше, чем
я ожидал и вполне прекрасно работающий:))!!!! Вывод: Мои мучения с
USB забыты, как в страшном сне, маздай остается чисто для игр,
для спокойной работы - Линукс, теперь подключил шнурок к коробке
USB-IDE и напрямую в Линуксе гоняй файлы туда-сюда, собствено
надобность в маздае полностью отпала, так же как и в w2k для дома,
просто не вижу смысла держать w2k дома, его линух делает повсякому,
а в свете того, что есть Win4Lin, так можно вообще не держать
маздай на отдельной партиции, если конечно не нужны игры, то этот
эмуль полностью дополнит Линукс-десктоп всякими маздайными
офисами и кучами винприложениями!!!:-)))

Я сделал свежие тесты lmbench-2.
Тестировались ядра 2.2.19p2, 2.3.40i1, 2.4.0, и FreeBSD-4.1.1 на одной и той же машине.
Кто интересуется, результаты можно посмотреть здесь: http://mylinux.newmail.ru/
Краткое резюме: фря отличилась только в одном тесте - AF Unix Local Communication bandwidths.
Опережение довольно существенное - 3 раза. В остальных тестах у фри во многих местах
просматривается заметное отставание. В том числе и в сетевых tcp/udp тестах.

anonymous (*) (2001-01-05 19:21:09.0) Поставь себе FreeBSD и забудь про проблемы. UPTIME 80 day и то только что у меня руки кривые пришлось RESET жать. Вся Ваша [*] дерьмо пользуй Windows Me для Q3 и не [*] мозги. Насчет первого предложения (Если ты конечно не красногласный студент, орущий Лихуй форевер). За грубость извините.

Друзья! А как в 2.4.0 проблема с memory hole между 15-16Mb решена? А то мне не сильно хочется ядро править!

Следи за своим базаром ;))

Если кому интересно, еще пару тестов без комментариев:
http://members.fortunecity.com/mrsi/linux2.2.18vs2.4.0.html

А у всех Serial driver version 5.02 (2000-08-09) компилится
with MANY_PORTS SHARE_IRQ или только у меня?

В конфиге это дело запрещено:

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set

2anonymous у которого фря в аптайме 80 дней.

[root@ant /root]# uname -m -r -s Linux 2.2.15-4mdk i686 [root@ant /root]# uptime 1:53pm up 89 days, 20:39, 2 users, load average: 0.00, 0.00 ...

я уверен, что еще полгода без перезагрузки проработает, i440GX SMP 2xPIII-500 Full SCSI

mail:~$ uname -a
FreeBSD mail.XXX.XXXX.XX 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Sun May 16 14:59:54
mail:~$ uptime
5:58пп up 89 days, 3:02, 4 users, load averages: 1.00, 1.00, 1.00
mail:~$ wc -l /etc/passwd
562 /etc/passwd
Последний раз ребутили по причине отключения лектричества.
Скоро будем делать апгрейд до 4.XX, так что дней 100-110 наберется.

Pasha.K

а почему ppp не работает? pppd говорит, что ядро не поддерживает... хотя: CONFIG_MODVERSIONS is not set CONFIG_PPP=y CONFIG_PPP_ASYNC=y и pppd версии 2.4.0

У меня все нормально работает, вот только беда, что-то с acpi не все гладко, точнее не с acpi... См: - -- $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs gcc version 2.95.3 20001229 (prerelease) $ uname -a Linux ice 2.4.0 #15 Fri Jan 5 21:36:49 MSK 2001 i686 unknown $ #libc6 2.2 $ ps {acpi_evaluate_object} {acpi_evaluate_object_R__ver_acpi_evaluate_object} Warning: /lib/modules/2.4.0/System.map does not match kernel data. {acpi_evaluate_object} {acpi_evaluate_object_R__ver_acpi_evaluate_object} Warning: /usr/src/linux/System.map does not match kernel data. PID TTY STAT TIME COMMAND [...] $ uptime 6:43pm up 1 day, 19:30, 4 users, load average: 0.00, 0.00, 0.00 $ _ - --

To anonymous (*) (2001-01-07 18:13:32.0)

#cd /usr/doc/ppp-2.4.0

и читай

Otherwise you will need to create a /dev/ppp device node with the
commands:

# mknod /dev/ppp c 108 0
# chmod 600 /dev/ppp

If you use module autoloading and have PPP as a module, you wil
to add the following to your /etc/modules.conf or /etc/conf.modules

/dev/ppp ppp_generic
alias char-major-108 ppp_generic
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate

Ну вот, пошла мериловка...

Аптайм - ни фига не значит. Вот, к примеру, жутко глючный UltraLinux:

[vsl@usparc vsl]$ uname -a
Linux usparc.тратата 2.2.14-5.0 #1 Tue Mar 7 21:50:41 EST 2000 sparc64 unknown

[vsl@usparc vsl]$ uptime
 11:48pm  up 95 days, 11:07,  1 user,  load average: 1.00, 1.00, 1.00

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

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

Я пришёл. Давненько меня тута небыло - работа, мать её...
По поводу мериловки - писал я тута как-то про свою проксю 2*PII-300 под Слакварью. Сегодня аптайма 99-й день. Пить буду. ;-)
Про 2.4.х: думаю, что надоть ждать, пока новая Слакварь выйдет. Честно говоря, вспоминая историю про 2.2.0, меня крайне ломает даже пробовать 2.4.х, пока не выйдет 2.4.5-е ядро...

Опять меряться пошли. Если так, то
http://uptime.netcraft.com/up/today/top.avg.html
Перед новым годом фря была на первой строчке

А что разве аптайм 90 дней это круто?

У меня рутер на РэдХат 6.0 полтора года без перезагрузки работает.
А Новелловский сервак (4.11) вообще три года.

а на нем *.bz2 не держат. Поэтому нормальные люди ходят на ftp.fi.kernel.org или ftp.at.kernel.org

>А Новелловский сервак (4.11) вообще три года.

Новелл рулез?

а ты это RH полтора года не апгрейдил ?
IP-адресочек скажи плиз ;)

я тоже сделал тесты 2.4.0 vs 2.2.18. на 2xPIII 500MHz, 1G PC100 памяти, 35G SCSI винт. использовал lmbench2beta1:
http://www.null.ru/pages/kmike/res.txt
вывод: 2.4.0 слил почти везде..

Слил - это в смысле проиграл? Я сразу вижу одну серьезную проблему в твоем
тесте. Она сильно бросается в глаза. Тест называется "File & VM system latencies".
Так вот, многочисленные независимые тесты показывают, что показатель
Mmap latency в 2.4.0 в 10-15 раз ниже, чем в 2.2. Твой тест показывает,
что этот параметр в 2.4 наоборот, в ...100 раз выше?!? Сорри, этот нонсенс.
Я конечно не исключаю возможности, что lmbench не приспособлен к SMP и
выдает совершенно искаженную информацию, но все равно выглядит это очень сомнительно.

А вот результаты dbench-теста гораздо интереснее. Это эмуляция самба-сервера.
И 2.4.0 здесь показывает свои способности. Примечательно, что пик производительности
приходится на 10 клиентов, в то время как у остальных он уже резко падает.
Данный тест показывает, что 2.4.0 очень крепко держится с увеличением нагрузки,
и для сильно загруженных серверов это очень неплохой кандидат. Конечно, после устранения
текущих багов... А так, довольно заманчиво: установка 2.4.х равносильно
апгрейду железа с увеличением мощности в 1.3-1.4 раза.

Тест лежит здесь: http://mylinux.newmail.ru/dbench_results.txt

2foreigner: я вообще-то сам немало удивился, видишь, сколько раз гонял тест...
не знаю, в чем еще может быть гемор, в железе вряд ли (сертифицированный сервак), в конфиге ядра ничего экстраординарного, и конфиги 2.4.0 и 2.2.18 максимально близки друг к другу.
а ты смотрел на результаты RSI? (http://members.fortunecity.com/mrsi/linux2.2.18vs2.4.0.html )
они, как мне кажется, ближе к моим, чем к твоим...

Посмотрел. У них правильный Mmap Latency. Как я и говорил: у 2.4.0 этот
показатель в 10-15 раз ниже. А теперь посмотри на свои результаты. Может у тебя
lmbench старый? Попробуй обновить на lmbench-2alpha12.

ну наверное это глюк конкретного lmbench-а, потому что он у меня _новее_, чем у тебя (lmbench2beta1, последний, от 10 января).
а как тогда объяснить отставание 2.4.0 по 90% остальных показателей?

P.S. сейчас скачаю alpha12, попробую с ней...
P.P.S. а какой размер файла для теста указывали, по умолчанию? просто 70% от 1 гига получается 700 мегов :), так что я 500 мегов указывал.. может дело в этом? поменьше попробовать?

In short, 2.4.0 - разочарование

докладываю результаты lmbench2alpha12:
http://www.null.ru/pages/kmike/res_alpha12.txt
кроме явного бага с mmap, других принципиальных отличий от lmbench2beta1 не обнаружено.
по-прежнему 2.4.0 медленнее 2.2.18 везде, кроме TCP & mmap latency и TCP bandwidth.