Linux kernel 2.4.20 is out

Вот и пошли первые сообщения о багах. Судя по всему при использовании ext3 в data=journal режиме и последующем umount данные на диск не попадают, если не сделать sync.

http://marc.theaimsgroup.com/?l=linux-kernel&m=102697320324406&w=2

Как же такой баг попал в релиз? Впрочем кто сказал, что попал? На странице по линку говорится про:

Subject: 2.4.19-rc1,2 + ext3 data=journal: data loss on unmount

Да и дата там совсем даже не вчерашняя: Date: 2002-07-18 6:12:49

:-)))))

а есть возможность мне встроить алсу в ядро не модулями а монолитно как в 2.5?

Нажми несколько раз на линку "Next in thread" попутно читая...

>Изменения по сравнению с 2.4.20 довольно значительны. 
Наверно все же по сравнению с 2.4.19? 

Я думаю, с ordered проблем не будет.
J.
P.S. А зачем нужна монолитная альса? Там есть скрипт в альсе, выкидывающий
oss - попробуй - может это оно?
(remove-oss, по-моему)

А вот поддержки Promise PDC20271 там не оказалось... А вот в какой-то pre-ac-чего-то там была...

Кошмар, кошмар! Я еще к старому привыкнуть не успел, а тут уже новое :-)

Прикол:
David S. Miller <davem@nuts.ninka.net>:
o NET: Backport 2.5.x NAPI infrastructure to 2.4.x
[...]
Marcelo Tosatti <marcelo@plucky.distro.conectiva>:
o Remove NAPI for now

а htb они наконец то туда воткнули? Впрочем сейчас посмотрю

Скомпилировал - работает отлично. Правда, при перетаскивании конфигурации с 2.4.18 куда-то делась HID Input Support, вследствии чего остался без клавиатуры и мыши. Перекомпилировал еще раз. Не без этого.

А на netraverse нет патчика к ядру. Грустно.

vot sigu zhdu poka grsec patch viydet dlya 2.4.20, togda i poydu stavit', a to bez grsec ne zhizn'

Патчики я подправил
Можешь брать и радоваться жизни :-)

http://www.8ka.mipt.ru/~wmd/w4lp.tar.bz2

а с XFS оно как?

Скачал, скомпилил, установил -- работает! Всё работает, никаких притензий!

Давно его ждал. Наконец-то! А то в силу новшества моего компа у меня не работало udma.(из-за чипсета i845G) Поставил, работает. Ура!

И че, это глюкало при большой нагрузке не падает в отличие от .19?

А кто-нть ac1 пробовал ставить на него? У меня что-то не ставится :-( "program cc1 got fatal signal 11"

>"это глюкало при большой нагрузке не падает в отличие от .19"

"это глюкало" не падает при большой загрузке начиная с ядра 2.4.19pre3aa2 которое я с марта успешно использую (у некоторых машин аптайм по 200 дней).

если у вас падает - то нужно ловить баг и писать соответствующим товарищам авторам ядра, обычно очень быстро помогает.

ps. а если сидеть и ничего не делать - то конечно "падать" будет

"program cc1 got fatal signal 11" - ты точно уверен что у тебя компьютер хорошо работает? ничего не разогнано? память memtest86 тестировал?

Проц не разгонял, память- нормальная, тестировал 2-мя тестилками(в т,ч, memtest86)

P.S. я 2.4.20 тоже поставить не могу :-( та же самая ошибка

>>у некоторых машин аптайм по 200 дней
чем озадачены эти машины??

А скажите плз, variable HZ, портированный из
2.5 Робертом Лавом, вошёл в этот релиз?

И ещё вопрос: вот вы все тут про memtest
говорите, а действительно ли он может
протестировать *всю* память? Ведь как мне
кажется, он может толко сделать malloc()
и потом mlock(), но память, принадлежащая
на этот момент другим процессам или ядру,
ему не должна отдаваться. А значит его
результат не может быть достоверным.
Я не прав?

А процессор не перегревается? Sig11 это _обычно_ либо память либо кулер... Либо баг в gcc :-).

> А процессор не перегревается? Sig11 это _обычно_ либо
> память либо кулер... Либо баг в gcc :-).
Да в gcc этих багов... Особенно в РедХатовском
2.96.х. Короче, пишите вот что:
ef gcc
и наслаждайтесь зрелищем:) Проверено на всех
gcc вплоть до 2.96.98-RH.

Не :-) переборщил я оказывается с версией make - поставил 3.80 - сейчас откатил назад до 3.79.1, родного 2 anonymous (*) (2002-12-01 04:08:19.423) А уж RH я совсем не пользуюсь, тем более его gcc :-)

А что за команда ef?

мужики, читайте changes (там и про gcc и про все остальное) вот только что сидел с iptables , колдовал минут 20, прочел changes и все стало понятно

> А что за команда ef?

localhost:~> ef
/usr/bin/ef: Usage: ef [executable] [arguments].
Runs the executable under the Electric Fence malloc debugger.

valgrind тож хорош.

> вот вы все тут про memtest > говорите, а действительно ли он может > протестировать *всю* память?

memtest86 работает безо всякого линукса, загружается с дискетки или через lilo. Поэтому никто ему не может помешать протестировать всю память. Другой вопрос, что прохождение теста не дает гарантии, что с памятью действительно всё OK.

http://www.memtest86.com/

2ifconfig >чем озадачены эти машины

базы данных + самописные программы для их обработки еще год-полтора назад 2.4.* падало "на ура" за неделю.

ps. это куча машин по 2cpu/1-2Gb ram/...

> memtest86 работает безо всякого линукса, загружается с дискетки или через lilo.
OK, thanks, наверное у меня тогда какой-то
другой memtest стоит. Просто запускаю команду
memtest, и он начинает тестировать.
Где брал - не помню, но видимо не с www.memtest86.com :(

green: таки что в итоге делать с щюткой юмора на предмет буферизациии ext3 ?

>"это глюкало" не падает при большой загрузке начиная с ядра >2.4.19pre3aa2 которое я с марта успешно использую (у некоторых машин >аптайм по 200 дней).

Ну 2.4.18 с kernel.org у мну тоже не падает под нагрузкой (вообще-то падает, но в известных ситуациях коих можно избежать ;-( ), а вот 2.4.19 или все 2.4.18 ядра от RH при LA>=6 изволят падать.

>если у вас падает - то нужно ловить баг и писать соответствующим >товарищам авторам ядра, обычно очень быстро помогает.

У меня, видите ли, продуктивный сервер, а не игрушка.
Ессно, результаты ksymoops отправлялись куда надо, реакции 0.
Не удивлюсь, что ситуация аналогична 2.2, когда у нас не держалось
ни одно ядро выше 2.2.13.

>ps. а если сидеть и ничего не делать - то конечно "падать" будет

Я сильно сорри, но
а) отлаживать мне негде
б) девелоперы линуха, как известно, делают его for fun, а не чтоб оно работало ;-))

1.
>девелоперы линуха, как известно, делают его for fun, а не чтоб оно работало ;-))

не все, но Линус меня в прошлом году угостил обещанием исправить багу
в ядре 2.5/6 - и меня это не порадовало. :-)

я общаюсь с SuSE-шниками - Andrea Arcangeli & Hubert Mantel.
можно сказать что только Andrea сделал ядро пригодным для нашего применения.

2.
>а вот 2.4.19 или все 2.4.18 ядра от RH при LA>=6 изволят падать.
такой LA - ненормально, это означает что несколько (6) задач сушат вафли. Что-то тормозит. Или памяти не хватает, или вообще на другой сервер передвинуть нужно. В общем - оптимизировать.

У меня 2.4.19pre3aa2 может работать несколько дней при LA=20-30 (потом нагрузка снижается). Но ничего не падает.

а каков вообще принцип расчета этого LA ?

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

По "man vmstat" это: "The number of processes waiting for run time".

> green:
Хоть я и не green, но отвечу:)

> таки что в итоге делать с щюткой юмора на предмет буферизациии ext3 ?
Ничего не делать. Сидеть и не рыпаться.
А что, неужели LKML никто не читает?:)
Вот ответ:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0212.0/0012.html

>я общаюсь с SuSE-шниками - Andrea Arcangeli & Hubert Mantel.
>можно сказать что только Andrea сделал ядро пригодным для нашего >применения.

Эх!
Многие до сих пор не могут использовать ядро 2.4, так как VM там до сих пор... :-(

>такой LA - ненормально, это означает что несколько (6) задач сушат >вафли. Что-то тормозит. Или памяти не хватает, или вообще на другой >сервер передвинуть нужно. В общем - оптимизировать.

Это в нашей ситуации нормально.
Что такое LA я как бы знаю :-)

>У меня 2.4.19pre3aa2 может работать несколько дней при LA=20-30 >(потом нагрузка снижается). Но ничего не падает.

И че ж не оптимизируете? ;-))))

Date: Sun, 01 Dec 2002 00:52:23 -0800
From: Andrew Morton <akpm@digeo.com>
Subject: Re: data corrupting bug in 2.4.20 ext3, data=journal

Please avoid ext3/data=journal until it is sorted out.

Ну или всегда делать sync перед umount файлухи в data=journal моде.

Кстати тут еще один баг вроде как раскопали. Subject страшный по крайней мере,
посмотрим что скажет Эндрю на это:
Subject: 2.4.20: ext3: Assertion failure in journal_forget() - filesystem destroyed
This started to happen during larger (10MB-420MB) rsync based writes to
a striped ext3 partition (/dev/md11) residing on 4 scsi disks which is
mounted with defaults, i.e. data=ordered (rsync over 100Mbps link):
...

>У меня 2.4.19pre3aa2 может работать несколько дней при LA=20-30 >(потом нагрузка снижается). Но ничего не падает.

>И че ж не оптимизируете? ;-))))

Случай сложный - задача не параллелизируется :)

anonymous (*) (2002-11-30 23:50:03.615) Прав. Под unix-like OS он попытается отожрать столько памяти, сколько сможет (при условии, что его аргумент - количество памяти для тестирования - больше того, что доступно на данный момент) и залочить её. Если не сможет - честно предупредит.

А вообше, тестирование памяти в работающей системе, как мне кажется, представляет только академический интерес.

L.

4lb: LA - это попугаи, измеряемые в слонах. Из всего софта на него полагается, до сих пор, кажется, только sendmail. И совершенно напрасно, потому что цифра бесполезная, а зачастую и вредная. Совершенно не отражающая реальное положение дел.

4lb: LA - это попугаи, измеряемые в слонах. Из всего софта на него полагается, до сих пор, кажется, только sendmail. И совершенно напрасно, потому что цифра бесполезная, а зачастую и вредная. Совершенно не отражающая реальное положение дел.

L.

"код для распознавания stack overflow в кернеле (не security фича) на x86, " - что это за штука такая? Включать ли ее или нет? И вообще, где можно почитать про буфер оверфлоу, стэк оферфлоу, срыв стэка и прочее в том же духе?

"а вот 2.4.19 или все 2.4.18 ядра от RH при LA>=6 изволят падать." - LA - это как расшифровывается?

2anonymous (*) (2002-12-02 13:59:14.636)

Только для тебя: LA - Los Angeles ж)