Да, тот кернел с другой машинки. там gcc из rawhide на 9й шапке. Там у меня ешшо руки не дошли собрать 2.4.21, завтра соберу

там где суся стоит ешшо руки не дошли 2.4.21 собрать в смысле ;)

www.tldp.org/HOWTO/MIPS-HOWTO-10.html

тут глянь www.tldp.org/HOWTO/MIPS-HOWTO-10.html

Эх... Судя по Компуленте, SCO ещё умудрилась и на Apple наехать... ;-)

Блин, буде такое в России, уже давно бы открыли охоту на менеджеров SCO и, в частности, на высший командный состав...

А тут - тишина... И, типа, чуть ли не IBM готова прогнуться под ублюдков. АФИГЕТЬ.

2green (*) (2003-06-16 22:13:02.780857): Эх... Если бы было всё так просто... Ты посмотри сырцы для IP22... Там ведь в них определяется всё, вплоть до прерываний и DMA-каналов... Если ядро собрать без этого, то никаких прерываний и DMA не будет: комп превратится в груду металлолома, чем он, по сути, и является.

Не, не SCO. Open Group

2anonymous (*) (2003-06-16 22:23:58.940779): Да читал я это всё. Оно, как раз-таки описывает глюки для SGI-IP22 (т. е., SGI Indigo2/Indy платформы), а у меня SGI Iris Indigo... Бред полный... Особенно, если учесть, что процессоры одинаковые везде...

2green (*) (2003-06-16 22:51:41.61724): А что, есть какая-то особенная разница?

Не понял. В чем определяется? в сырцах? Дык и отлично, ты ж сырцы то и собираешь. Или оно при компиляции берет всю эту инфу из текущей системы?С трудом верется, но тогда должен быть способ все задать внешним образом

Конечно есть, это совершенно разные вещи, как я понимаю. SCO - коммерческая контора, Open Group - типа какой то там чуть ли не комитет по проверке соответствия и разработке стандартов.

2green:
>>А как быть с MMX и SSE регистрами? Они тоже сохраняются,
>>или где?
>Тоже сохраняются при переключениях контекста между разными userspace задачами,
А вот тут уже не понятно.
Скажем, собрал я ядро для 486, а проги на нём гоняю с
поддержкой SSE... Как оно в этом случае будет SSE-регистры
сохранять?

2FoodTechnologist: если не лень ли Section "Module" а также Section "Device" из XF86Config, а также то, что выводится при запуске XFree86 на stderr/stdout мылом на nodashi&mail.ru? Будет интересно посмотреть...

Ну оно ж смотрит в CPU capabilities на тему того какие регистры есть, а каких нет.

кстати 2.4.20 правда не собиралось gcc3.3. Были некоторые баги в коде reiserfs. (это green в твой огород камень ;) ). В 2.4.21 все ок.

2green:
Слушай, а у меня вот такой вопрос: а почему все эти проблемы с модулями FPU/MMX/SSE(2)/3dNow нельзя решить на уровне ассемблерного кода?
Пример. С MTRR всё решили: умудрились в одном модуле задействовать аналогичные регистры кучи процессоров (PII/III/IV, Cyrix, AMD...). Круто.
Но что мешает аналогичным образом поступить с сопроцессорами? Типа через #ifdef прогнать модули FPU/MMX/SSE/SSE2/3dNOW??? Заодно можно было бы и задел на будущее создать (то бишь, есть ассемблерный код и оптимизированные функции с общими интерфейсами) на предмет, если VIA разродится чем-то типа "VIA Now" или Intel родит "SSE3".

В общем, лично у меня уже давно непонятки с политикой kernel team в области сопроцессоров (в этой категории я понимаю всё: FPU/MMX/SSE/SSE2/3dNow). Сопроцессоры для того и создавались (за то и деньги платят покупатели), чтобы увеличить быстродействие компьютеров... А тут выясняется, что люди попросту вышвырнули бабки "на ветер", заплатив за SSE2...

А не в мой ;) не я его писал, тот код. Как выплыло - так и пофиксили. А некомпилилось еще кое-что, в сети там помнится были extern inline, например, и тп.

Эти регистры слишком дорого сохранять/ресторить. Но там где оно того и правда стоит - это делается. А SSE2 - оно не пропадает, его аппликейшены используют, если захотят, конечно.

2 anonymous (*) (2003-06-16 19:45:42.784242)

> Это чистый gcc(c ftp.gnu.org) или подвергнутый "художественной" переработке каким либо производителем дистрибутов ? Если чистый - буду весьма признателен ВЫ поделитесь набром пачей и методом сборки сего продкта ...

тот что в Debian/unstable
патчи можно взять здесь: ftp://ftp.debian.org/debian/pool/main/g/gcc-3.3/gcc-3.3_3.3ds9-3.diff.gz
Метод сборки можно подсмотреть в debian/rules.

толи редхатовцы уроды, толи одно из двух.
pthread_cleanup_(pop|push) в шляпе девятой глючит не подетски...
ктонить чтонить смог сделать?

2green (*) (2003-06-16 22:53:13.790323): Ну, судя по всему, бинарник ядра сам говорит Ириске, для какой системы оно надо. Когда я пытался загрузить ядро Debian для SGI, Ириска написала, что, мол, совершенно не знает, что за платформа SGI-IP22 и грузить ядро отказалась.

:>chuchelo (*) (2003-06-17 08:15:02.81876) A глянь какая версия nptl - если больше 0.43 - то может дело в этом ...

>Эти регистры слишком дорого сохранять/ресторить.
Насколько я знаю резон совсем не в этом:
FPU из ядра (из драйверов) был выброшен из соображений 

Portability:    Pointers are not always 32bits, people do not all have
                floating point and you shouldn't use inline x86 assembler in
                your driver without careful thought. Pure x86 drivers
                generally are not popular. If you only have x86 hardware it
                is hard to test portability but it is easy to make sure the
                code can easily be made portable.

А сохранение контекста сопра юзается при каждом mmx_memcpy()
то есть при каждом copy_to_user()/copy_from_user() если копируемый
кусок больше 512 байт 

мне уже ответили насчет pthrad_cleanup_ функций.
Щас попробую слинковать с pthraed библиотекой что в /lib
лежит, а не в /usr/lib (в /usr/lib лежит ntpl как раз)

Гм а в 9й шапке devfs пофиксили или нет ?

:> тот что в Debian/unstable долбиан кстати поступает очень мудро чесно говорит чего это за продукт но я его не юзаю - а пачи там специфичны для дебиана но большое мерси в любом случае - пороюсь на досуге

А че там фиксить? вроде ничего особо и не сломано, правда сам я devfs не юзаю, но надо было как-то сделать имаг для uml'я который бы использовал devfs - сделался с полпинка

так, линковать pthread программы надо с тем что лежит в /lib или в /lib/i686 а как это сделать без прятания /lib/tls? (с ним линкует по умолчанию)

По оценкам Торвальдса, в этом месяце должна выйти следующая версия ядра Linux, 2.6.??? http://www.zdnet.ru/?ID=302231

-L<пач к дире> -l<либа>

2green

дык в 9й шапке кернел не компилися с devfs - нужен был малюсенький пач

вот и спрашиваю - пофиксили это или нет ?

Или по другому - посмотри на libpthread.so - это должен быть текстовичок типа

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )

Поправь его как тебе надо и тогда без всякого гемора будешь линковать
все как тебе надо по умолчанию

Ну незнаю. в ванилла кернеле devfs компилится, а шапошные кернела я не юзаю, туда плохо накладываются нужные мне патчи.

Я смотрю в CVS glibc появилась db2 дира - похоже хотят влить bdb - хорошо бы , а то блин задолбала уже свистопляска с кучей версий этой самой bdb.

Файл сделал, на мыло пока не сброшу - не мой комп. Со своего в очередной раз в инет выйду - сброшу.
Покопался в этом выводе. Оказалось:
1. Сбой в GLXе. Если его отключить (или поставить месовский), иксы загрузятся.
2. Даже если их загрузить, в консоль оттуда не вернуться.

Обнаружил ещё кое-что. Патч packetcd отрубает все функциональные клавиши в консоли (кроме переключения терминалов)

-L не помогает хоть что указывай хоть в каком порядке линкует с /lib/tls если имеет к нему доступ.

Кстати апологетам gcc 3.2.x, - "gcc-3.2.2 miscompiles kernel 2.4.* O_DIRECT code", gcc 3.3 fixes the problem. в lkml msgid <20030617123745.GA5717@verdi.et.tudelft.nl>

а в /usr/lib/libpthread.so и так по умолчанию записано:

OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
/usr/lib/libpthread.so

никакого указания на /lib/tls

...

>Кстати апологетам gcc 3.2.x, - "gcc-3.2.2 miscompiles kernel 2.4.* O_DIRECT code", gcc 3.3 fixes the problem. в lkml msgid <20030617123745.GA5717@verdi.et.tudelft.nl>

Это скорее апологетам RH ;))

"...I found out that O_DIRECT does not work correctly on 2.4 kernels
compiled with the RH gcc-3.2.2-5 on RH9. It is working fine with
kernels compiled with the RH gcc-2.96-113 on RH 7.3." 

libpthread.so.0 у тебя либа или симлинк ?

Мужики, блин, ну неужели сам никто этого gcc-3.3 не собирал ?

Дык собирается оно без всяких шаманских плясок, просто собирается и все. по инструкции - configure ; make ; make install

А откуда, ты думаешь, у шапки этот gcc? ;)

угу - если б он еще после этого работал прилично ....

короче -fsaa -minline-all-stringops -fschedule* -fmerge* -fpeephole* в gcc-3.2.3 практически не вызывают осложнений, чего нельзя сказать про 3.3x.

anonymous (*) (2003-06-17 20:57:56.628808)
смотря какая, в редхате таких файлов аж пять штук :-)
какой надо? :-)))

ну тебе ж там на месте должно быть видней - или ты уже разгребся с линковкой libpth ?

Доброго времени суток. По поводу gcc-3.3 - пришлось собирать на новой числодробилке, поскольку в нем есть такие ключики как -mcpu=athlon-pm и -march=ahlon-mp. В итоге выигрыш на приложениях - 25-30%. Собиратеся в легкую ... просто необходимо прочиать в директории_куда _распокавали_сырцы/INSTALL доки.Если не ошибаюсь ./configure make bootstrap make install Далее по поводу ядра 2.4.21 - никаких болтов при компилляции не возникло. Более того, если гцц собирать под конкретную машину - ядро компиллиьтся намного быстрее. Загрузка идет как по маслу. Про ключики не знаю... достаточно прописать -mpcu=athlon-mp -march=athlon-mp для более оптмиального кода. Система работает пошустрее (чисто субъективно, конечно, но если нужны циферы - собираюсь протестить в режиме интенсивного I/O - на задачах в 10 Гб и более).

С уважением, $echo.

>но если нужны циферы - собираюсь протестить в режиме >интенсивного I/O - на задачах в 10 Гб и более

цифры естественно нужны, как потестишь кинь сюда ссылку

Да усть не забыл. Дистрибутив Debian Wolf. Не спать, пахать, пахать ... -)