[quote=rolano]Строчки, на которых все обрывается я вам дать не могу:
1. Если писать то, что остается на экране, то нужно обладать просто офигенной скоростью восприятия м обработки информации, а читать по остаточным статическим зарядам на люминофоре я пока не научился...
[/quote]
Если вывод команды не уместился на экране, то просмотреть "улетевшую" часть можно нажав Shift+PgUp - это азы Линукса, если этого не знаешь, то пока ядра собирать рановато...

Может оперативка битая?

Или проц разогнал..

Может попробовать несжатое собрать?

По поводу оперативки и разогнанных железяк. Проц работает на номинале, уменьшены тайминги памяти, но в Виндах вроде проблем не наблюдалось как на легких, так и на тяжелых приложениях. Память, правда, не тестировал. Вопрос - если RAM битая, то почему падение происходит именно на последнем этапе?
По поводу сборки несжатого ядра.
1. Оно получается немаленькое - около 3,5 метров. LILO его принимать не хочет - великовато, говорит.
2. Архиваторы работают номально, поэтому проблема судя по всему именно в компиляторе. Если это так, то я не смогу собрать по-человечески ни одну прогу (а хочется).

В Сети прочитал, что с компиляторами gcc 4.х имеются именно такие траблы с падением. А что скажет по этому поводу Коллективный разум?

аааа
4й гцц еще сыроват
поищи на диске compatible-gcc и поставь

Даже самый разнестабильный компилятор не может перегрузить или завесить систему. Почитайте что-нибудь о защищенном решиме, kernelspace, userspace, Ring 0, Ring 3 и т.д,, чтобы не садиться в лужу с такими заявлениями. А автору темы: для начала прогони memtest86+. Вообще 99.9%, что у тебя проблема с "железом".

Даже самый разнестабильный компилятор не может перегрузить или завесить систему? Вы считаете, что приложение в принципе не может повесить систему? Не стоит так категорично заявлять. Всегда находятся бреши и недоработки, только одни из них приводят к неработоспособности софта (чаще), другие - к падению всей системы (намного реже). Уважаемый Nick, Вы так и не высказались по поводу наличия проблем в gcc 4.х. Если у Вас нет сведений об этом, то так и скажите (или выскажите Ваше мнение по поводу gcc 4.х).

Ваш совет по тестированию памяти приму к сведению и апробирую на практике, но есть ряд вопросов:

1. Почему компилятор падает в конце процесса, а не где-то в случайном месте? Фразы типа "gcc жрет память только на последнем этапе" не слишком убедительны. Нормально работают X и KDE, другие софтины.
2. Почему виндовский софт и игры работают нормально, хотя уж они-то память жрут просто немерено и вероятность попасть в битый участок намного выше; а где синий экран смерти (очень давно его не было)?

P.S. Резкий тон высказываний прошу понять, т.к.

Недоработки есть, конечно. Если система виснет -- это ошибка в ядре. Поставь свежее ядро для твоего дистрибутива.

Кстати, сжатием ядра занимается не компилятор, а gzip

Уважаемый Nick!
С ядром-то как раз и проблема - хочу поставить, но оно не собирается. У меня 2 схемы памяти - 256 и 128 МБ. Первую из них я вчера проверял Microsoft Windows Memory Diagnostic и MemTest86+. Обе проги запускались без операционных систем с загрузочных дисков. WMMD все тесты прогнал без ошибок, MemTest86+ прошел все тесты кроме одного - Modulo 20, ones&zeros (или что-то такое). Он у меня стопился то на 2 процентах, то на 12, хотя софтварно рисуемый плюсик мигал как положено, поэтому я этот тест благополучно пропустил и все списал на собственное нежелание ждать. Все тесты с пересылкой данных, применением масок и т.д. прошли без ошибок. Сборка ядра на одном модуле памяти приводит все к тому же результату. Можно ли теперь считать предположение о битой памяти неверным?
Сейчас сливаю с Нета gcc 3.3, попробую накатить его.
Возможен вариант, что у меня стоит глючный gzip? Если да, то почему сжатые файлы нормально открываются в mc (паковать, правда, не пробовал)?
Может попробовать собрать ядро в Слакваре 9.1 (он на каком-то 2.4.х), поставить module-init и жить спокойно?

gzip ядро не свалит. Вообще никакая userspace-программа не свалит kernelspace, если это не глюк ядра. А свежее ядро из дистрибутива ставится при помощи rpm, а не gcc.

[quote=Nick]gzip ядро не свалит. Вообще никакая userspace-программа не свалит kernelspace, если это не глюк ядра. А свежее ядро из дистрибутива ставится при помощи rpm, а не gcc.[/quote]
Улыбнуло...
РПМные йадра неоптимизированны. поэтому смысла нет их ставить.
Я ставлю из исходников ядро. Были проблемы - думанием и чтением документации их решил.

Предложение поставить ядро из rpm очень не нравится. Оно собиралось ниезвестно кем неизвестно где и незнамо под какие системы. Я не хочу просто поменять шило на мыло, я хочу пересобрать ядро: есть желание поэкспериментировать и пооптимизировать и вообще - это бесценный опыт.
Уважаемый Developer! Решить проблему думанием и чтением документации я пробовал, пока ничего не придумал и не начитал, потому и обратился за помощью к Коллективному разуму. Читал и Kernel-HOWTO, и другие статьи - но нигде я не нашел ответа на свой вопрос: почему я не могу получить сжатое ядро в своей системе? Советы типа "читай и думай" слишком общие, я так тоже могу сказать любому. Если есть конкретная мысль - милости прошу.

пробовал другую версию ядра??? поновее??? а еще лучше более раннюю попробуй...

Пробовал 2.6.8.1 и 2.6.9. Из линейки 2.4 ничего не пробовал. Возникает резонный вопрос - почему не собирается стабильное ядро? Туча яйцеголовык дядек эти ядра тестировали, а тут вдруг я такой с кандачка нашел их упущения :-)
Вообще на 2.4 переходить не хочу. На фиг мне тогда вообще Мандрейк 10, если можно поставить Слакварь 9.1?

пробовал эти ядра компилировать на другой машине??? или ОСе??? мошт именно траблы с файлами исходников ядра... мошт компилер глючит...

мне кажется, что это чисто программные траблы...

А меня тут убеждают, что на 99,9% проблемы с железом. Компилить на другой тачке не могу - нету у меня другой тачки.

пробуй линух иной... поставь ту же VMWare, в ней линух какой-нить, быстренько так, без иксов, с минимум, только шоп попробовать ядро скомпилить...

С чего ты взял, что оно стабильное? Сами разработчики уже давно сказали, что стабильные ядра только дистрибутивные, а ядра с kernel.org -- это вечная бета-версия.

А не стоит ли проанализировать настройки ядра, makefile, что выводится последним, логи при зависании, какие версии пакетов использовались при сборке (родные, или сам собирал?)... А то Вы тут гадаете на кофейной гуще и не имея никакой информации пытаетесь попасть в десяточку.

PS. Сам я ядро собирал всего два раза, и оба раза неудачно :) %-6 :( ;) !beer

[quote=Nick]С чего ты взял, что оно стабильное? Сами разработчики уже давно сказали, что стабильные ядра только дистрибутивные, а ядра с kernel.org -- это вечная бета-версия.
[/quote]
Разработчики чего? :)

Ядра.

а чтож они пишут
The latest [b]stable version[/b] of the Linux kernel is: 2.6.12.5 2005-08-15 00:43 UTC ?

[quote=rolano]Стоит Mandrake 10.1 на ядре 2.6.8.1-mdk. При попытке собрать ядра 2.6.8.1 и 2.6.9 в конце процесса, когда должен появиться файл сжатого ядра, машина перезагружается или намертво виснет. В чем может быит причина?[/quote]

А выдай-ка нам свои команды сборки ядра пожалуйста:
make .. .. .. ?

Я пробовал make, make bzImage, но разницы никакой.
По поводу стабильности ядер - ну если на kernel.org выкладывают фуфло, тогда вся идея о бесплатной устойчивой операционке - в заднице. Если к ОСе нет стабильного ядра, тогда нет смысла её дальше поддерживать. На хрена мне тогда Линух, если нельзя поковырять внутренности, при таком раскладе можно и Виндой обойтись.

йопт это у тебя не в ядре дело. А скорее всего в мандрайке.
make images собирает?
варнинги при сборке дает?
В конце процесса это года? Когда надпись появилась GZIP .... или раньше? У тебя может линковщик чтото сломася...

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

Думус ты как всегда злой... Низя так...

Уважаемый Dumus! Если Вы такой умный (череп случаем не жмет?), тогда может снизойдете до того, чтобы дать практический совет? Про кривые руки - вопросы о кривизне различных объектов будут иметь разные ответы в зависимости от контекста их рассмотрения

Уважаемый Ролано! Да уж, не дурак; в каждом архиве с кернелом, если вы ещё не в курсе, идёт подробнейшая инструкция по сборке, очень рекомендую её почитать, перед тем как копья ломать. Удачи!
[ Редактирование 25.08.2005 - 14:00:26 ]

[quote=rolano]Уважаемый Dumus! Если Вы такой умный (череп случаем не жмет?), тогда может снизойдете до того, чтобы дать практический совет? Про кривые руки - вопросы о кривизне различных объектов будут иметь разные ответы в зависимости от контекста их рассмотрения[/quote]
Что вы развозмущались? Мы от вас не увидели даже строчки на которой происходит зависание, подробностей - минимум. Так что вы хотите? Телепаты в отпуске. При ваших "подробностях" первое что пришло в голову - это проблема с железом.

Строчки, на которых все обрывается я вам дать не могу:
1. Если писать то, что остается на экране, то нужно обладать просто офигенной скоростью восприятия м обработки информации, а читать по остаточным статическим зарядам на люминофоре я пока не научился
2. Если перенаправлять вывод в файл, то он все равно не будет полным. Или вы не знали, что Линух старается кешировать операции чтения/записи на диск?
Единственное, что могу сказать, что были с троки с BUILD и GZIP
3. Инструкции по сборке я читал не один раз, все по ним и делал, только вот где результат?

Своими словами я никого не хотел обидеть. Может Вы думаете, что если я задал вопрос в ламерском разделе, то я стопроцентно тупой геймер, который вдруг случайно поставил Линух? А давать советы типа "читай документацию и просто руки у тебя кривые" - дело нехитрое. Я понимаю, что пока у меня нет навыков работы с Линухом, ну а у кого они из Вас были, когда Вы сами начинали?

Уважаемый rolano,
если memtest не проходит - надо убрать разгон памяти. Эмпирически отмеченный лично мною факт - все почти всегда работает, но иногда система намертво виснет:
1. Прогоняю мемтест - ошибки
2. Возвращаю тайминги памяти в то, что им положено
3. Прогоняю мемтест - все ОК.
4. Больше ничего не виснет.

Рекомендую этот метод. После можно попробовать пересобрать ядро заново. Если глюк не уйдет - продолжим обсуждение.
Т.о. сначала надо убрать ВСЕ возможные аппаратные причины, а затем можно поискать и программные.

Тайиминги я итак поставил на максимальные значения, но все равно на 6-й тест в memtest я так и не прошел (или же он настольно медленный, что за час ожидание не сделал даже одного процента). Остальные тесты не выдают никаких ошибок. Тестировал с помощью Microsoft Windows Memory Diagnostic - все тесты без ошибок. Ну согласитесь, что не может память нормально читаться и записываться в тестах, не вызывать синих экранов смерти в Винде, но быть все равно быть глючной? В чем же тогда её глюк?
Память - это единственный компонент, параметры которого я пробовал менять.

Какая версия memtest'а?
Какое железо?

1.27

Celeron 1100, Ram - 256+128 HYNDAI/NYNIX, Chaintech 6OJA3T на i815, HDD Quantum Fireball 40AS на 40ГБ и Seagete Barrakuda на 120 ГБ

Если интересно, то пробовал тестить память раздельно, но результат не менялся

Странно.
Я, вообще, memtest'у больше верю, чем Windows Memory Diagnostic, но все возможно, в конце концов.
Сам я ядрами 2.6 не пользуюсь, дисциплина разработки у них не очень (иначе было бы только 2.6.12 и никаких 2.6.12.1 и т.д.), но собирал. Проблем со сборкой не было. Опять-таки, компилятор 4.x пока только для самых смелых :-) Лучше надежный проверенный 3.3, в прошлом при смене компиляторов gcc/cygnus 2.xx на gcc 3 уже проблемы были именно со сборкой ядра.
Но если виснет вся система, все-таки, скорее всего, причина в железе. Или в _запущенном_ ядре, а не в собираемом...

А lsmod что показывает?

Если причина в железе, тогда в каком? Почему в Винде все работает без сбоев и падений, а тут - полный аут? По gcc 4.х вы один из немногих высказавшихся, хотя я вопрос задавал (больше всего люди пеняют на железо и кривые руки). Собственно, этот компилятор - не мой выбор, а Мандрейка. Если проблема в запущенном ядре, тогда выходит, что либо Мандрейк не умеет собирато корректно ядра, либо нехочет, чтобы конечный пользователь это делал самостоятельно. Первое противоречит коммерческой целесобразности, второе - принципам рапространения и использования Linux.

А при чем здесь lsmod?

При том, что кто-то убивает ядро. Кто это делает, можно попытаться определить по списку модулей, так как намертво повесить саму систему может только железяка или ядро.

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

По поводу lsmod - довольно странно. Как можно распространять дистрибутив, если что-то родное убивает систему (типа Калькулятора в ранних WindowsXP). Как буду собирать - обязательно посмотрю. Может мне выбросить на фиг эти дистрибы и сесть на Слакварь (пусть и не такой новый - 9.1), но у меня от него остались хорошие впечатления?

1. Понятно, что при определенных комбинациях железа/софта могут возникать глюки. Все на всем протестить невозможно :-)
2. Ну, можно и на Мандраке, наверное жить :-))).
Сейчас попробуем определить, есть ли в системе gcc-3.x
Что говорит rpm -qa | grep gcc ?

Да я сейчас не имею доступа в камише с Linux, она дома стоит

А если отвлечься от конкретной проблемы, то что Вы можете посоветовать из дистрибутивов по собственному опыту?

[quote=rolano]Строчки, на которых все обрывается я вам дать не могу:
[/quote]
make чтонадо 2>&1 | tee make.log 1>&2

Потом вгружаежся и читаеж и сюда последних 10 строк постиш

[color=brown]Народ хватит флемить то[/color]
<span class='smallblacktext'>[ Редактирование 25.08.2005 - 16:56:47 ]</span>