Linux kernel 2.4.21 is out

bootsplash встал, правда -F 150 пришлось патчу укзать. щас ребутнусь :-)

нда, какая-то странная методика разработки - бэкпорты. Это тоже самое, если мс будет улучшать вын95, беря куски кода из ХР

нда, какая-то странная методика разработки - бэкпорты. Это тоже самое, если мс будет улучшать вын95, беря куски кода из ХР

Нет это как если в WinXP будут перекидываться наработки разработчиков Longhorn

А ACPI в нем древнее как незнаю кто... Не уж то не могли обновить
до последнего, да еще agpgart под nForce2 не вошел, правда это
мелочь, а вот без поддержки ACPI при работе с современными
материнками уже имеются некоторые трудности с выделением IRQ,
это раньше можно было вырубить ACPI и все железо нормально
виделось, сейчас этот номер не проходит, особенно с
интегрированой переферией типа USB, сетевух, звуковух и т.д...
Кстати, ACPI v.2.0a сейчас идет почти на всех материнках nForce2, i875/865, VIA KT400A, SIS655/658, в линуксе ACPI работает пока
нормально на интеловских матерях, а на остальных неопределенно...:(

На счет ACPI был нешуточный спор между Марсело и разработчиком из Intel. Этот разработчик говорил что в 2.4 ветке 18 месяцев не обновлялся код ACPI и он настоятельно просил принять патчи, на что Марсело ответил что патчи слишком большие и он применит их только в ветке 2.4.23-preX.

Кстати, тот самый разработчик, в ответ на слова Марсело, предлагал 500$ в случае если будут какие нибуть проблемы с его патчами. ;-)))

Вывод: осталось совсем чуть-чуть и в 2.4 будет хороший ACPI... тем кому не терпится могут опробовать ветку 2.5.

"совсем скоро" - это никак не меньше полугода в лучшем случае.

2logIN: Владельцам интелевых мамок радоваться есть чему, а вот
например мне, владельцу матери на nForce2, нечему, пробовал
ставить последние патчи ACPI драйвера, проблема с прерываниями,
не один модуль загрузиться не может, хотя в таблице роутинга IRQ
все прерывания раздались вплодь до двадцать какого-то, вообщем
ACPI от интел только для интел, что тоже не есть хорошо. А проблему
с ACPI надо ставить во главу проблем и решать, иначе будет железо
не на все 100% работать, у меня например без ACPI не работает
один из 3х USB хабов на материнке, никакие ручные перестановки
и назначения IRQ в биосе не помагают, правда если отключить
поддержку USB v2.0 то хаб оживает. Обещают правда сделать поддержку для nForce2, только вемени уже прошло много, а все
никак не сделают, заняться что ли этой проблемой....

Пока ядро нравится. На предылущем, когда просыпался bdflush система вставала раком на пару секунд. С новым ядром такого не заметно.

""совсем скоро" - это никак не меньше полугода в лучшем случае."

Марсело обещал, что 2.4.22 будет очень быстрым релизом (по сравнению с другими).


"Владельцам интелевых мамок радоваться есть чему, а вот
например мне, владельцу матери на nForce2, нечему"

Могу только посочувствовать.. Intel видимо больше заботится о своих клиентах.

btw, ты пробовал ветку 2.5 ? Может там уже nForce работает?

Такс, grsecurity тоже уже быстренько вышел - зер гуд, респект Браду.
Теперь ждем mcp и его детище WOLK, тогда можно будет переезжать.. А пока 2.4.20 + wolk4.2s работает стабильно.

>btw, ты пробовал ветку 2.5 ? Может там уже nForce работает?

2logIN: Дело не в ветке, а в том, что ACPI детище интеля, я
нашел способ как залочить на конретную мать и биос ACPI
драйвер, только это решение работает с последней версией
ACPI, которое в ядро не вошло, описание метода есть на
http://acpi.sourceforge.net/wiki/index.php, а конкретно через
DSDT таблицу, для этого надо взять утилитки с интеловского
сайта и проделать всю операцию как написано в HOWTO,
только ядро получается завязано на конкретную мамку и
номер биоса. Я хочу попробовать этот способ и сообщу, что
получилось...

А что вы, собственно, привязались к nForce2?
У меня на 2.4.21-pre5-ac3 все зашибись работает:
agp: driver nvidia
sound: i810: NVIDIA nForce Audio found at IO 0xd400 and 0xd000, MEM 0x0000 and 0x0000, IRQ 11
hdd ultra dma

Чего еще надо-то?

Ага, вот и народ, наконец, заметил проблему с ACPI.
А я мучаюсь уже больше года с ним на своём Compaq presario.
Где-то раза с пятого надоело качать патчи и я забил на это дело.
Неужели можно надеяться что ACPI заработает вскоре?

2All: Вы лучше расскажите, как новый код для IDE-дисков работает? Нормально? А то мне в понедельник ядра менять у серверов... Обидно будет, если глючный драйвер IDE убьёт ReiserFS... :-(

to ROOT с луговским чего еси не секрет

ядра ветки Кокса (-ac) регулярно патчатся кем то из Интела на предмет ACPI, вы changelog'и смотрите?
так что всем страждащим стоит попробовать -ac ветку прежде чем искать другое лечение

а в 2.4.21 поддержка XFS есть?

2ROOT: Безумству храбрых поем мы песню... Да подожди ты пару недель, в первый день после выпуска релиза кидаться его ставить на сервера - то же самое, что ставить Win до первого сервиспака. Поставь к себе на рабочую станцию, погоняй. Серьезно говорю - не ставь новое ядро пока не пройдет две недели. Баг с ext3 помнишь? А 2.4.11-dontuse?

P.S.: прошелся по логам изменений, с интересом "застукал" там не так мало русских, (а чаще всего встречаются Кузнецов в NET/IPV4/IPV6 и... green с патчами на предмет memory leak где ни попадя :-)), нашел, что ребята из IBM не боятся и продолжают работать над ядром вместе с остльным наробом :-) и еще много интересных вещей.

Да вот ACPI эт проблема, поставил я както 2.4.18 на мою мать, и время от времени комп просто начал виснуть намертво, не пинговался и незя было залогинится удаленно, я долга копал, уже на модем начал посматривать, так ничего и не нашел, потом пропатчил ACPI и все с тех пор все пучком, единствунная хрень теперь это если в биосе выключить ACPI то вынь не грузится :) а линукс грузится, если включить то вынь грузится а линь иксы не хочет запускать :) мож кто че посоветует? мне оно особо не мешает в билс лазить каждый раз, я в основном тока в лине и сижу, но все же......

Итак, ядро 2.4.21 прекрасно собирается и работает с RedHat 9 (несмотря на многчисленные заверения от некоторых джентльменов в обратном :-)) Двадцать минут, полет нормальный :-)

Хотя нет, не все так гладко, а точнее - я откровенно гоню. Перестал работать mplayer, и связано это действительно с поддержкой thread'ов. Т.е. перестали работать те приложения, которые multithread. Опс!

ну так в том то и разница ядер от шапки 9 от тех что на kernel.org(2.4.x) - новые треды... наверное не только они

2anonymous (*) (2003-06-14 07:23:33.529163): А ничего. Он мне так и не позвонил... ;-) А искать его у меня всякое желание пропало: на работе завал, да тут ещё и подготовка к свадьбе опять-же... В общем, можно считать, что ему повезло.

2no-dashi (*) (2003-06-14 09:19:16.839312): Да вот я как раз-таки и вопрос задал именно из воспоминаний про всю эту бадягу. (сам я тогда не "попал" именно потому, что решил месяцок подождать, перед тем, как ядро новое ставить; да и ext3 я не юзаю - предпочитаю ReiserFS). Насторожило несколько, что "Применен патч, который должен значительно улучшить поведение системы при массивной дисковой нагрузке, особенно на IDE системах"
Раз уж ты его запустил (ядро в смысле), попробуй его GCC 3.2.2 собрать с примерно такими CFLAGS="-O9 -mpentium4 -msse2 -fomit-frame-pointer -pipe -s" (если у тебя машина P4, конечно) только не забудь, что это нужно прописать не только в /usr/src/linux/Makefile (заменить все строки с -O2), но и в /usr/src/linux/тря-ля-ля/i386/Makefile (заменить уродское "-march=i686 -mcpu=pentiumpro" в строке оптимизации для P4)) К сожалению, я не помню все ключики полностью, с которыми я собирал 2.4.20 (там их порядка 2-х десятков), но с этими ключиками 2.4.21 просто обязано работать.

2no-dashi (*) (2003-06-14 11:03:01.970285): Как это?!?!? Ядро ведь должно треды-то... Хм... Может, это mplayer так по-извращенному напильником обработан???

Не флейма ради, а удовольствия для:
<offtopic>
Кстати, это то, про что я ж не раз предупреждал: дистрибутив Шапки становится бинарно несовместим даже с оригинальным ядром...
</offtopic>

а зачем ядро собирать с такой фашистской оптимизацией? оно же содержит руками съоптимизированого кода, который компилер уже улучшить не может(inline asm например)
еще в дебиановском мэйл-листе один из мантейнеров популярно объяснил что собирать glibc под i686 не только не выгодно, но и опасно. такая же ситуация с ядром я думаю...

имхо прирост производительности системы от оптимизации ядра, практически не заметен, ядро это не самое узкое место в системе с которого нужно начинать оптимизацию.

Народ, а что, в свежих версиях gcc есть смысл ставить -O больше 3 ?
Ибо как -O9 это то же самое, что -O3

Ага, быстрым. то есть два - три месяца по его же словам. Потом в 2.4.23-pre1 замержат ACPI, и то что 2.4.23 будет быстрым релизом никто не обещал. То есть в релизном ядре ACPI появится еще не скоро.

Вроде IDE работает. по крайней мере я никаких проблем не наблюдаю пока (в смысле уже целую неделю).

Нет и не ожидается

ой, а у меня все работает. Может у тебя не настоящая rh9, а та которая beta1? там была эта проблема, но с тех пор ее давно исправили.

НИКОГДА нельзя собирать с -msse -msse2 ядро! Предполагается что ядро не использует FPU и SSE/SSE2, потому все эти регистры не сохраняются на переключениях userspace->кернел->userspace (ну кроме некоторых специальных мест где они явно сохраняются и используются тоже явно).

>А то мне в понедельник ядра менять у серверов...

ищешь приключений на свою задницу?

Тут однажды процесс занимавший /tmp завис в состоянии D. (RH 7.2 2.4.7-10) После чего весь /tmp стал нечитаемым. Где-то я прочитал, что в новых ядрах что-то сделали с этим. Если да, то я срочно сменю ядро.

<cite> еще в дебиановском мэйл-листе один из мантейнеров популярно объяснил что собирать glibc под i686 не только не выгодно, но и опасно </cite>

А нельзя ли URL сиих объяснений? Ини какие-нибудь цитаты, дабы можно было это письмо зацепить через Google.

Поди аргументы были плана "а когда вы воткнете собранную таким образом glibc в обычный pentium/i486 - настанет вам жестокий облом" ;)

awn (*) (2003-06-14 13:40:32.043007)
извини, я потерял ссылку, я рылся в архиве мэйл-листа на предмет испортит ли мне apt-build make-world мою установку, и случайно наткнулся

green (*) (2003-06-14 13:42:09.817988)
нет, их давно разводят на i586 и выше собирать пакеты, но приводились аргументы что expensive optimisation в самом деле оказывается expensive... во время исполнения

для 386 и 486 есть "маленькие" дебианчики давно, и основную массу такой переход не затронул бы

2MakcuM (*) (2003-06-14 12:44:42.128322): Это прикол просто ;-). Конечно, GCC всё, что >= -O3 понимает, как -O3.

2green (*) (2003-06-14 13:01:01.882763): Хм... Странно... Может, что-то где-то "не то"? Особенно, в твоём постинге...
Лично у меня, ядро, SAMBA, Apache, PHP, MySQL, Sendmail, BIND и кое-что ещё собраны с такой оптимизацией (-mpentium3 -msse). Чего-то глюки незаметны. (причём, Apache, MySQL, Sendmail и BIND - под юзерскими правами).
Всё работает, как часы уже почти с неделю (собственно, с тех пор, как я на тот сервак 9-ю Слакварь поставил)...

2green (*) (2003-06-14 13:01:01.882763): Ещё в догонку: а как быть с информацией в man gcc, где белым по черному написано, что все свободные регистры СPU, FPU, SSE(1,2) и 3dNow как раз-таки используются для передачи содержимого переменных при переходе между функциями??? (т. е., gcc старается как можно больше кода откомпилировать так, чтобы везде делался inline)

В man'е на gcc написано что sse/sse2 не испоьзуется пока явно не попросишь. FPU регистры для передачи параметров в кернеле не используются потому что там нету вычислений с плаваюзей точкой. То что ты проблем не замечаешь не о чем не говорит на самом деле. мож просто везет, например. Но то что кернел нельзя компилить с -msse, -msse2 - факт.

Комменты: у меня мать на via kt400 - ACPI вырублено и все ок. APM начало работать только в 2.5.69. ======================= А на кой черт собирать все с туевой хучей ключей, если glibc'ы собраны под i386 - вся оптимизация на смарку. Вы хоть понимаете, что GNU libc - это основа скорости программ?

Что касается оптимизации то рекомендую посмотреть gentoo, в котором как в source-based дистрибутиве вопросы оптимизации крайне важня для функционирования системы: Например при сборке glibc нужно отключить только filter-flags "-fomit-frame-pointer -malign-double" т.е. сойдет -mcpu=pentium4 -O3 Кстати ядро действительно собирается без поддержки sse & 3dnow

2green (*) (2003-06-14 14:48:49.762481): А можно поподробнее? Ссылочку, например...
Просто если делать выводы из твоих слов, вся система должна была повиснуть буквально сразу же: т. е. при переходе (к примеру) ядро<->samba часть инфы кидается в блок sse, но (при этом) эта инфа не сохраняется... В результате ядро (демон) получают лишь часть переменных "правильно", а остальное - случайный набор данных. Я правильно понял? Вопрос, в таком случае, простой: а почему этого не происходит? Особенно, при вторичной компиляции (типа из-под такого ядра собирать ту же Самбу, к примеру, и с такими же параметрами)???

2anonymous (*) (2003-06-14 14:49:29.164966): Хм... Что тебе на это ответить? Да, от GLIBC зависит многое... Вот только я тест такой делал в своё время: на i486DX4-100 компилил ядро со стандартной оптимизацией и со своей (-O9 -march=i486 -mcpu=486 -fexpensive-optimizations -finline-functions -pipe -s на "старом" GCC) в резeльтате: 486-я в сетевой 1-й Quake рисовала на 10fps больше... Это при том, что она максимум 50fps рисова вообще... ;-) Т. е., в том случае, был прирост производительности порядка 20-25%. Есть о чём задуматься... Ессно, в случае PIV прирост в производительности будет не столь явным, но всё же...

logIN (*) (2003-06-14 00:51:09.314244)
> Кстати, тот самый разработчик, в ответ на слова Марсело,
> предлагал 500$ в случае если будут какие нибуть проблемы
> с его патчами. ;-)))
Как интересно, а ссылку можно? Мож 500$ получу:)))

no-dashi (*) (2003-06-14 09:19:16.839312)
> green с патчами на предмет memory leak где ни попадя :-)),
> нашел, что ребята из IBM не боятся и продолжают работать
> над ядром вместе с
> остльным наробом :-) и еще много интересных вещей.
Да это ещё что, вон в ядрах -ac вообще какие-то патчи на
тему dos4gw наши хлопцы делали, а ведь при чём тут dos4gw,
казалось бы??

R00T (*) (2003-06-14 14:28:08.978636)
> свободные регистры СPU, FPU, SSE(1,2) и 3dNow как раз-таки
> используются для передачи содержимого переменных при переходе
> между функциями???
Всего лишь ИМХО: green говорил про переключение контекстов
между ядром и юзерспейсом, а не про переходы между
функциями в процессе пользователя.
Я бы тоже не стал ядро с поддержкой sse собирать, пока
в структуре sigcontext <asm/sigcontext.h> эти регистры
не появятся, да и, имхо, green знает что говорит (надеюсь:)

кстати о ядре и оптимизациях, на 2.4.21-rc2 провел тест: скомпилил ядро с одним и тем же конфом на О2 и О3 оптимизациях. ядро с оптимизацией О2 сессно меньше, но это уже другой разговор. проблема в том, что в ядре с О3 оптимизацией напрочь отказался работать сдром. при этом в О2 ядре все ок, полет нормальный. есть какие-нибудь мысли по этому поводу?

Ссылочку так сразу найти не могу, но недавно в lkml на эту тему была дискуссия.

2green, расскажите пожалуйста, что такое lkml и я сам попробую поискать.

2anonymous (*) (2003-06-14 15:16:04.672451): CDROM, конечно, IDE? Тот самый проапгрейженный IDE-драйвер?
-O3 от -O2 отличается, насколько я помню, всего-лишь одним флажком (одно из 3-х: -finline-functions, -fomit-frame-pointer или -fexpensive-optimizations - у кого man gcc под рукой, поправьте меня).

В общем, вывод делай сам: в 2.4.20 все эти ключики работают намана.

2anonymous (*) (2003-06-14 15:24:31.142947): lkml == Linux Kernel Mail List... Я так понимаю, с www.kernel.org туда попасть можно.

2green: Слушай, а давай я тебе в понедельник пришлю своё ядро, ключики и .config? Не хочешь покопаться?