2ROOT

> Интересно, что же они пихают внутрь из периферии? > Не удивлюсь, если винты от Seagate и ту же уродскую > память от Hynix или Samsung...

Ну-ка, ну-ка... Расскажи, чем тебе винты Seagate не нравятся и память от ведущего производителя чипов ? Что-то я в последнее время, по большей части, только Samsung вижу под марками Kingston и Transcend. В Цисках, опять же, их модули, в нортеловских железках частенько... Модулей RIMM вообще не встречал от другого производителя, тут даже сборка их.

Вот все говорят про патчи Alan Cox (-ac), а кто-нибудь может плохое сказать про патчи Andrea Arcangelli (-aa)? XFS там есть, плюс патчи Andrea на тему VM. aa патчи использую давно на сервера ставлю всегда, проблем не было ни разу после нормальной месячной обкатки на своих рабочих станциях. ac патчи пугают тем, что там постоянный процесс правки IDE :(

-ac патчи - это основа кернелов от RH.
-aa патчи - это основа кернелов от SuSE.
это типа в упрощенном виде.

2AS (*) (2003-06-15 19:24:06.149589): А не нравятся тем же, чем не нравятся телевизоры (мониторы, ЖК-матрицы, жесткие диски, телевизоры, стиральные машины и прочее) пр-ва Samsung: всё это корейский ширпотреб, печатный станок, включенный на полную катушку. Точно так же, как Daewoo, кстати - они тоже выпускают то телевизоры с мониторами, то автомобили...
В моей печальной практике была примерно такая статистика: на 10 модулей памяти под маркой "Samsung Original" приходился один глючный модуль. То же самое по поводу Hyundai-Hynix. Самое смешное, что в модулях Jetram/Trancend и Kingston глюков находить как-то не доводилось. Хотя оно и верно: в эти модули зачастую пихают микрухи от Samsing и Hynix... Но то ли производственные серии заказывают специальные, то ли тестируют как-то по-особенному, но глюков незаметно.
Плюс, опять же, гарантийные обязательства - типа если найдешь глюк в модуле, поменяют без разговоров хоть через сто лет... ;-) А у Samsung я никогда не видел гарантии ни на что больше, чем 3 года.

Покупай Kingston Value RAM и будут тебе глюки ;) А через три года это все будет уже либо копейки, либо уже даже если захотят поменять - не смогут, потому как нету ни у кого и не делает никто.

Так что гарантия даже на три года - по большей части фикция.

>Значится по пунктам:
>drivers/net/hamradio/soundmodem/gentbl.c - в кернел не вкомпиливается, >а используется при построении кернела для генерации какихто >табличек. Не в тему то бишь.

Угу - это я не глядя сделал cut&paste ;)

>drivers/video/cyberfb.c - обрати внимание на "#if 0" вокруг floating point вычислений.

...но код то есть :)

>drivers/video/sgivwfb.c - обрати внимание на '#error "Floating point not allowed in kernel"' перед первым floating поинт вычислением, очевидно что этот код в кернел ты не вкомпиляешь.

ну это скорее всего "склерозник" для того чтоб потом пофиксить :)
кстати судя по всему сей кусок не для x86 а там float point может быть
вполне себе FPU context safe

А вот код ЯВНО использующий FPU ;)
drivers/video/sis/sis_main.c

вот кусок с FP
static int sisfb_do_set_var(struct fb_var_screeninfo *var, int isactive,
struct fb_info *info)
{
unsigned int htotal = 0, vtotal = 0;
double drate = 0, hrate = 0;
...
#error "Code in to the kernel (sS) !!!"
// добавлено мной ....

gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.20/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=sis_main -DEXPORT_SYMTAB -c sis_main.c
sis_main.c:700: #error "Code in to the kernel (sS) !!!"
make[3]: *** [sis_main.o] Ошибка 1

Собственно все это из за того что "no float point in to the kernel"
не "факт" а "правило" - из которого как известно есть исключения
сие правило как было уже замечено связано с тем что при прерывании
задачи ядро явно не сохраняет контекст FPU/MMX (в x86) - правда это можно сделать непосредственно перед использованием FPU/MMX в нашем кернельном коде _рукопашную_ но стоит ли такой геморрой свеч ? ;)


Отсюда в вывода:

1)FPU код может быть в ядре но он там нежелетелен
2)Оптимизация с использованием SSE/SSE2/3DNow _компилятором_
имеет мало смысла ввиду почти полного отсутствия предмета оптимизации :)

Про то что его можно использовать если сохраняешь контекст руками я сразу сказал. Кое-где гемморой таки стоит свеч. Например на пентиумах через fpu получается быстрее копировать. (или на чем там?).

А в sis_main.c - кернел баг явно. Там этот sisfb_do_set_var() используется при sisfb_switch() так что если console_switch сделать в неправильный момент - все может развалиться на куски запросто.

А у меня с новым ядром в /var/log/messages стали регулярно появлятся такие сообщения из 3ёх строк:

hda: dma_timer_expiry: dma status == 0x24 hda: dma_intr: bad DMA status (dma_stat=30) hda: dma_intr: status=0x50 { DriveReady SeekComplete }

никто не просветит нормально ли это и что это значит?

2green (*) (2003-06-15 21:50:55.722674)

>Про то что его можно использовать если сохраняешь контекст руками >я сразу сказал. Кое-где гемморой таки стоит свеч. Например на >пентиумах через fpu получается быстрее копировать. (или на чем >там?).

Ну там вроде бы юзается MMX - это как бы все же не float point(логически) ;)

>sis_main.c - кернел баг явно. Там этот sisfb_do_set_var() используется >при sisfb_switch() так что если console_switch сделать в неправильный >момент - все может развалиться на куски запросто.

как я понял если _не_ используется preemptive kernel - сей баг будет
опасен только для user space задач - использующих FP

2green (*) (2003-06-15 21:02:22.13746): Вот ты знаешь, мне из Кокосии привезли модуль Transcend (64Mb SIMM для ноутбука Nec Versa 4000) выпуска ХЗ когда. Но _НОВЫЙ_. И тоже с письмом о пижизненной гарантии.

2anonymous (*) (2003-06-15 21:56:49.597865): А вот у меня, кстати, тоже такие вежи рисует (и ещё на ядрах типа 2.4.18 рисовала). Но только на Asus TUSL2-C и только если винт - Maxtor или тот же Seagate. С IBM и WD винтами всё ок.
Точно такую же мессагу будет тебе рисовать, если попробуешь hdparm'ом выставить UDMA-5 режим.

Я так понимаю, что глюк как раз связан с какой-то глючной реализацией перехода в UDMA-режим (ядро при запуске "автоматом" пытается выставить UDMA).

Не, бывают же пентиумы и не MMX :)

По поводу FP - конечно для userspace задач баг опасен. А если эта userspace задача - XFree86 - тебе будет легче? ;)

За твой счет поди привезли? ;)

>Не, бывают же пентиумы и не MMX :) 
Может я чего пропустил насчет копирования с помощю FPU ?
я думал речь об _mmx_memcpy() ?

>А вот у меня, кстати, тоже такие вежи рисует (и ещё на ядрах типа 2.4.18 рисовала). Но только на Asus TUSL2-C и только если винт - Maxtor или тот же Seagate. С IBM и WD винтами всё ок. >Точно такую же мессагу будет тебе рисовать, если попробуешь hdparm'ом выставить UDMA-5 режим.

Хм, винт действительно seagate barracuda ata IV и hdparm показал udma-5 но руками hdparm ни разу не запускал, наверное выставилось автоматом. На 2.4.19 такого не замечал, может смотрел плохо... Вобщем насколько я понял это железячный глюк и правилное лечение это замена винта?

Нет, было еще memcpy который копировал через FPU. правда в стандартное ядро так и не вошел, как я вижу. А ешшо FPU какой-то из чексуммеров для raid5 использует. (asm-i386/xor.h)

Чего-то не ясно с MMX и иже с ними... Ну в ядре нет ладно, но что же это ядро чтоли не сохраняет MMX контекст задач ? Получается компилить с MMX ВООБЩЕ ничего нельзя ? Или я жестоко гоню (надеюсь) ?!!!

кстати по топику .... вот этот код из i386/kernel/time.c if(count > LATCH) { printk(KERN_WARNING "i8253 count too high! resetting..\n"); outb_p(0x34, 0x43); outb_p(LATCH & 0xff, 0x40); outb(LATCH >> 8, 0x40); count = LATCH - 1; } Постоянно гадит в лог - чем лечить сие дело ??? Просто закоментить printk() :) ? (в 2.4.19 этого куска еще небыло)

>Чего-то не ясно с MMX и иже с ними... Ну в ядре нет ладно, но что же >это ядро чтоли не сохраняет MMX контекст задач ? Получается >компилить с MMX ВООБЩЕ ничего нельзя ? Или я жестоко гоню >(надеюсь) ?!!!

За сохранение контекста отвечает компилятор (если он умеет MMX/SSE/...) либо ты сам - если этого компилятор не умеет - проблема с ядром заключается в том что ось может прервать выполнение юзверь сейс задачи на совершенно произвольном месте и если _в ядре_ не предусмотреть средства сохранения контекста FPU/MMX при их использовании унутри ядра - то при возврате в юзверь спейс ты просто теряешь контекст FPU - так понятнее ?

>>так понятнее ? Да - я именно об этом. Именно потому что выполнение может прерватся в произвольном месте за сохраниние контекста должно отвечать ядро. А оно НЕ ОТВЕЧАЕТ ?!!

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

Да это известно, причем давно, только толку от этого мало, не работает
ACPI с не интелевыми мамками. Только что пробовал метод с DSDT
таблицей, не помогло, грузится ядро и все вкомпиленые драйвера
нормально находят прерывания, доходит до загрузки первого модуля
и виснит насмерть, что этой заразе еще надо!? Слышал краем уха,
что ACPI за январь-февраль вроде как работала с nForce2 от ASUS'а,
но опять таки это не факт, что будет работать на матери от Epox....

>А что вы, собственно, привязались к 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
>Чего еще надо-то?

2Toster: Это мало! AGP у тебя работает благодаря NVidia, а если
к примеру у тебя ATI или другая какая-нибудь карточка? AGPGART
наконец сделали и есть в последнем патче от Кокса. Я не знаю
что у тебя за звуковуха, но у меня с 5.1 и славу богу драйвер от
nvidia есть, а еще есть сетевуха, драйвер на нее закрыт, и это
тоже не очень хорошо, поддержка IDE под nForce2 появилось в pre3
может еще раньше, но самое главное для матерей на этом
чипсете - ACPI. Почему? Из-за IRQ роутинга, эта фича наверное
самая важная в ACPI, так как такая поддержка позволяет виртуально
назначать любой номер IRQ при старте OC. Вот почему при отключении
ACPI в биосе не стартуют Windows XP, если они ставились при
включеной ACPI, и вот почему не работают все шесть USB портов
на материнке в режиме USB v.1.1 + v.2.0, а работают только 4-е,
если нет поддержки ACPI в ОС. Про ACPI можно дохрена рассказывать,
некоторые по ошибке считают, что APM это тот же самый ACPI,
но ведь APM существует и без ACPI, ACPI может выполнять функции
APM, но не заменяет его....

NVidia у меня не работает.Собирается драйвер хорошо, запускается, после чего на экране висит красивый логотип NV и не только не загружает иксы, а начисто блокирует переключение в консоль (вернее, переключение есть - клавиатура работает, а на экране - логотип).

Я имею в виду, что не работает под 2.4.21 И патч от packetcd пока прикрутить не могу

R00T (*) (2003-06-15 16:09:28.073986) <offtop> почти угадал имел опыт общения с аквариусом (и сейчас на них раьотаю) год назад они ставили винты Samsung - намоейц машитне 2 винта с интрервалом в 2 недели сдохло... :-( сейчас вроде исправились и сьавят Seagate и IBM а карточка графическая на работеу меня моя старая домашняя TNT2 стоит, потому что то что шло с машной мылило изображение при разрешении 1024*768 (теперь в столе валяется) память встречается как Samsung так и Henix такое впечатление что они в свои "бренды" пихают то что на складе завалялось.... мамки либо MSI либо, если повзет Asus - это единственное к чему нет претензий при всем при этом машины тормозят жутко... по поводу периферии вообще молчу лучше бы они туда клаву с ммышой вообще не клали (таскать было бы легче) у нас у всех мыша с клавой свои :-) ЗЫ А сервер ихней сборки зато никаких нареканий не вызвал, а от Acer очень даже вызвал :-) </offtop>

Все, проблема устранена с запуском mplayer'а устранена, всем спасибо за советы. Баг был "промежуточный" - т.е. уже не в mplayer'е, но еще не в ядре :-) В общем, виноватым оказался -vo gl и libGLcore от NVidia, вот так. Теперь, после изничтожения -vo gl вроде бы все работает.

P.S.: кажется, я хочу кого-то убить...

2F-dT-t: какой процессор, какая видяшка, и что говорят по этому поводу в документации из /usr/share/doc/NVIDIA*/* ???

>NVidia у меня не работает.Собирается драйвер хорошо, запускается,
>после чего на экране висит красивый логотип NV и не только не
>загружает иксы, а начисто блокирует переключение в консоль
>(вернее, переключение есть - клавиатура работает, а на экране -
>логотип).

2FoodTechnologist: Имеется ввиду AGPGART с поддержкой nForce2?
В чистом 2.4.21 его нет, есть только в патчах у Кокса, работать
это драйвер с нвидевскими драйверами не обязан принципиально,
это хак для карточек не от нвидиа, поставь в XF86Config
в секции "Device"
Option "NvAgp" "1"
все должно заработать....

>. Именно потому что выполнение может прерватся в произвольном >месте за сохраниние контекста должно отвечать ядро. А оно НЕ >ОТВЕЧАЕТ ?!!
Нет - save_init_fpu()/restore_fpu() никто не отменял :)

AFAIK существуют как минимум 2 засады
при использовании FPU в ядре
1) SMP
2) preemtible kernel

2sS: ну слава тебе господи. самое главное что сохраняется контекст пользовательских задач... А ядро... Ядро доделают :)

А почему бы не спросить в lkml? Там посоветуют правильней и авторитетней ;)

Оно отвечает только в случае переключения контекстов. Но в случае прерываний/сисколлов - нет. Чем больше регистров ты сохраняешь - тем больше времени context switch. Одно только сохранение FPU state уже весьма заметная операция. (а glibc, которая при старте программы обнуляет регистры FPU - делает все только хуже, так как керне отслеживает для кажного процесса менялся ли FPU state, и если нет - то не сохраняет его.)

"Продолжение банкета" между nVidia, RedHat 9 и мной :-)

Итак, завести mplayer мне удалось, и на радостях я решил сыграть разок в tuxracer :-) Вы, наверное, уже угадали мою следующую фразу: tuxracer не запустился с той же ошибкой: not enough tread-local storage :-( То же самое происходит и со всеми qt-приложениями... Естественно, что меня это не устроило, и началось "копание" nVidia на предмет патченых драйверов, и вот что было найдено решение:

если запустить инсталяшку линуксового "детонатора" с ключиком --force-tls=classic, это решает вышеописанные проблемы :-)

Offtopic about kernel build

2green наверное, но может кто еще подскажет.

я к примеру собирал какое то ядро(от РХ9), у меня есть к нему .config

выходит новое, 2.4.21 - могу ли я свой .config подсунуть новому ядру, не словив глюков, или все таки надо в новом ядре конфигурить все с нуля?

интересует возможно ли подобное в общем случае, при переходе с ядра на ядро...

\\ Sanya

Можешь, но тебе прийдется сперва сделать make oldconfig и доответить на все вопросы, ответов на коотрые нету в твоем старом .config. К тому же если твое предыдущее ядро было сильно патченным (как в случае ядра от RH), то в новом непатченном ядре может неоказаться многих фич. Так что насчет "не словив глюков" - в общем случае не попробовав не узнаешь.

поставил 2.4.21-ac1 + patch-int-2.4.20.1 ,
всё работает.

NVidia 31.23 собралась и работает,
vmware-3.2 тоже собралась и работает,
звук emu10k1-v0.20a с sf.net работает,
шифрование работает,
резак через ide-scsi пашет,
никаких левых сообщений в messages замечено не было

> NVidia у меня не работает.Собирается драйвер хорошо, > запускается, после чего на экране висит красивый логотип NV и не > только не загружает иксы, а начисто блокирует переключение в > консоль (вернее, переключение есть - клавиатура работает, а на > экране - логотип).

У меня работает.

FOX Toolkit

>А почему бы не спросить в lkml? Там посоветуют правильней и авторитетней ;)

Уже пошел ... :)

Ради интереса подсовывал RedHat-овские конфиги в стандартные ядра.
Идея не лишена привлекательности, но IMHO лучше так не делать - даже
при включении всего, чего только можно, модулями (а оно так и есть в
конфигурациях RH), ядро "от RedHat" получается тяжелым. Некоторые
"циферки":

Версия ядра  Used,MB   Cache,MB
 2.4.20-8      68         44     -- стандартное ядро RH
 2.4.20-8m     40         21     -- облегченное ядро RH
 2.4.21        32         16     -- облегченое стандертное ядро

Система последовательно загружалась с разными ядрами, после чего
сразу смотрелся "top". Немного некорректное тестирование, зато
очень просто и эффектно :-)

Ах, да - забыл самое главное: стандартное ядро с коняигом RH: цифры были 51 и 27, соответственно...

народ, а у меня после переезда на KT333 стало вылетать в kernel panic (связано с CD, CD-RW): kt333+8235, promise, резак teac-w540, dvd asus616 - часто вылетает при нарезке или когда пото мделаешь cmp /dev/scd isoImage
причём похожая конфа (но не DVD) на работе работает на ура.
ядра 2.4.20
promise? via? cd?

>Имеется ввиду AGPGART с поддержкой nForce2? Какой nForce2? У меня простая Vanta с 16 М. А драйверы - от NVidia, с их знаменитым собираемым модулем для ядра. Пробовал последние (сборка, установка - руками) и предпоследние (с автоустановкой) - в общем, те, что на их сайте лежат. Ядро было - 2.4.20 (стандартное)+ с поддержкой Win4Lin (который я так и не поставил) и с поддержкой packetcd. Стало - 2.4.21 (packetcd не наложился). Никаких -ac и в помине нет. Т.е., резюмирую: драйвер nvidia (вроде, 4363): модуль ядра компилируется, устанавливается со стандартным ругательством про ГПЛ, сами драйвера (драйвер nvidiа) картинку показывают, а дальше - всё (что-то похожее у меня уже было при некорректной работе с dga). Драйвер nv работает прекрасно, но про OpenGL можно забыть. Rivafb, в принципе, работает (если его включить - с nvidia его надо выклюючать), но когда ставлю в иксы fbdev, то частота выскакивает за границы монитора.

Кстати, tuxracer, разумеется, идёт... На программном OpenGL :)

кстати packetcd сейчас в каком состоянии находится? работает?

Под 2.4.20 работал. Хотя и не очень хорошо с буферами. Да и UDF на записи русскую кодовую страницу каверкал.

тут брал патчи? http://w1.894.telia.com/~u89404340/patches/packet/

ОК, с FPU контекстом разобрались, для пользовательских
процессов он сохраняется и даже в struct sigcontext
присутствует.
А как быть с MMX и SSE регистрами? Они тоже сохраняются,
или где?

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

Наверно, здесь! Появился!

Вот уже и oops полезли из 2.4.21 Идиотский консерватизм Марсело нихера не дает

Читаю тут про сохранение контекста и недоумеваю... Вы зачем отделяете FPU кипирование от MMX копирования ?! Да быдет вам известно, MMX команды _НЕ_ВЫПОЛНЯЮТСЯ_ одновременно с FPU командами, т.к. MMX регистры проецируются (mmx0..mmx7) на FPU регистры. Так что не важно какое копирование. Любое такое капировние в ядре - это уже однозначно ЛАЖА!!!

2SCREW: >>Любое такое капировние в ядре - это уже однозначно ЛАЖА!!! Сохранение контекста пользовательских задач лажа ?!! :)))

;)

>Читаю тут про сохранение контекста и недоумеваю... Вы зачем отделяете >FPU кипирование от MMX копирования ?! Да быдет вам известно, MMX >команды _НЕ_ВЫПОЛНЯЮТСЯ_ одновременно с FPU командами, т.к. MMX >регистры проецируются (mmx0..mmx7) на FPU регистры.

спасибо что открыл нам глаза :))

> Так что не важно 
>какое копирование. Любое такое капировние в ядре - это уже однозначно >ЛАЖА!!!

Ну научи нас, темных как _правильно_ копировать :)