nixp.ru v3.0

19 апреля 2024,
пятница,
07:24:19 MSK

Sasha2 написал 10 августа 2005 года в 18:22 (795 просмотров) Ведет себя неопределенно; открыл 108 тем в форуме, оставил 880 комментариев на сайте.

Интересно узнать, у кого нибудь работает 3D ускорение для новых ATI карт на Fedora Core 4.

Там используется новый gcc4, а драйвера от ATI (8.14.13) сделаны с помощью gcc3.*

Поэтому, вероятнее всего 3D и не работает.

Интерсно, можно ли как-нибудь эту проблему преодолеть.

Сразу говорю таклй метод как yum ati-fglrx kernel-module-fglrx-$(unmae -r) не предлагать.

Точно не работающий.

Между прочим, когда этот вышеуказанный метод работает (например на Fedora 3), то тогда работает с таким же успехом и родной инсталлер (да и простые rpm пакеты) от ATI.

А вот когда не работает этот инсталлер, то и yum также не работает.

Также не стоит предлагать пересборку ядра.

Уж как только не пересобирал, все равно 3D не включается.

А вот в Fedora Core 3, там другой эффект, как не пересобирай ядро все равно 3D включается и работает отлично при любых вариантах сборки.

Также не следует предлагать такой чепухи типа UseInternalAGP=no или yes, или ChipID = тому то и тому то, хотя на Интернете всяких таких советов полно. Драйвера ATI давно уже не грешат такими багами, и это вообще ни на что не влияет.

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

С уважением

Адександр

anonymous

Вот патч для компиляции с gcc 4.x

diff -urN fglrx-vanilla/firegl_public.c fglrx/firegl_public.c
--- fglrx-vanilla/firegl_public.c      2005-06-12 20:56:30.000000000 +0200
+++ fglrx/firegl_public.c      2005-06-30 00:19:24.000000000 +0200
@@ -167,7 +167,7 @@
 #if !defined(__ia64__)
 // the macros do use errno variable
-static int errno;
+int errno;
 #endif // __ia64__
 // int mlock(const void *addr, size_t len);
@@ -347,10 +347,10 @@
 #define fops_get(fops)      (fops); MOD_INC_USE_COUNT
 #endif // LINUX_VERSION_CODE < 0x020400
-#define DRM_MODULE_GET          (firegl_drm_stub_info_t *)inter_module_get("drm")
+#define DRM_MODULE_GET          (firegl_drm_stub_info_t *)inter_module_get_request("drm","drm")
 #define DRM_MODULE_PUT          inter_module_put("drm")
-#define DRM_AGP_MODULE_GET      (drm_agp_t *)inter_module_get("drm_agp")
+#define DRM_AGP_MODULE_GET      (drm_agp_t *)inter_module_get_request("drm_agp","drm_agp")
 #define DRM_AGP_MODULE_PUT      inter_module_put("drm_agp")
 unsigned long ATI_API_CALL __ke_cpu_to_le32(unsigned long _u)
diff -urN fglrx/agp_backend.h fglrx-vanilla/agp_backend.h
--- fglrx/agp_backend.h      2005-06-12 20:56:04.000000000 +0200
+++ fglrx-vanilla/agp_backend.h      2005-06-30 00:37:34.000000000 +0200
@@ -89,7 +89,7 @@
 #define _X(_x) __fgl_##_x
 extern int _X(agp_init)(void);
 extern void _X(agp_cleanup)(void);
-extern int _X(agp_try_unsupported);
+static int _X(agp_try_unsupported);
 #else /* Original AGPGART module */
 #define STANDALONE_AGPGART
 #define _X(_x) _x
diff -urN fglrx/agpgart_be.c fglrx-vanilla/agpgart_be.c
--- fglrx/agpgart_be.c      2005-06-30 00:38:38.000000000 +0200
+++ fglrx-vanilla/agpgart_be.c      2005-06-30 00:38:02.000000000 +0200
@@ -176,7 +176,7 @@
 #ifdef STANDALONE_AGPGART
 static int agp_try_unsupported __initdata = 0;
 #else /* !STANDALONE_AGPGART */
-int agp_try_unsupported = 0;
+static int agp_try_unsupported = 0;
 #endif /* !STANDALONE_AGPGART */
 int agp_memory_reserved;

Ну и после него обязательно.


cp libfglrx_ip.a.GCC3 libfglrx_ip.a.GCC4 [code]
Sasha2

Нет, объясните пожалуйста более подробно.

Метод с использованием патча (и одного и двух я использовал также).

Все равно это не работает.

Как этот патч применять?

Например, если при использовании livna.org.

В какую директорию я должен скопировать этот патч?

Как его назвать?

И как применить?

И наверно, должны быть выполнены еще какие-то предварительные условия, чтобы это срабоало (если это вообще работает).

Да кстати, вот Вы написали, но сами то Вы попробовали его.

Т.е. можете ли Вы точно сказать: Я ПОПРОБОВАЛ ТАК-ТО И ТАК-ТО И У МЕНЯ ЭТО ЗАРАБОТАЛО?

С уважением

Александр

Sasha2

Да и еще вдогон, какая карта (модель)?

И версия ядра (исходное или пересобранное, какая версия)?

Может быть Вы говорите о ранней карте (до модели 9600 включительно).

Так они работают и без этих премудростей.

anonymous
Sasha2
Я ПОПРОБОВАЛ ТАК-ТО И ТАК-ТО И У МЕНЯ ЭТО ЗАРАБОТАЛО?

Ладно с самого начала:

rpm -ivh fglrx_6_8_0-8.14.13-1.i386.rpm --force
cd /lib/modules/fglrx/build_mod/
cp fglrx-2.6.12-rc6-2005-06-14.diff fglrx-8.14.13-alt-2.6.12-agp.patch fglrx-gcc4-patch.diff /lib/modules/fglrx/build_mod/
patch -i fglrx-2.6.12-rc6-2005-06-14.diff
patch -p1 -i fglrx-8.14.13-alt-2.6.12-agp.patch
patch -i fglrx-linux-2_1.6.12-gcc4.diff
cp libfglrx_ip.a.GCC3 libfglrx_ip.a.GCC4
sh make.sh
cd /lib/modules/fglrx/
sh make_install.sh

Вот собственно и всё. Ядро 2.6.13-rc6-git2 + GCC 4.0.1 и всё нормально работает.

P.S. Если нужны патчи то могу выслать.

Sasha2

Спасибо, вот теперь понятно?

Ну, что ж попробую еще раз.

Если Вас не затруднит вышлите пожалуйста патчи на адрес

gorodnov2@tochka.ru

С уважением Александр

Sasha2

А вообще, уважаемый Blackman, Вы знаете, все таки Вы не правы и вот почему:

У Вас по всей видимости дистрибутив Gentoo.

Но вот на сайте Gentoo самая последняя версия тестируемого (я уже не говорю о стабильном GCC) компилятора GCC это 3.4.4 (а вот стабильного 3.3.5.20050130-r2).

Поэтому, Выше ядро собрано уж точно не на компиляторе gcc4, может быть Вы и умдрились как то поставить компилятор этой версии (тогда вопрос, Вы пересобирали ядро при помощи этого компилятора?), но дело ведь не в этом. Дело в том, что Ваше ядро собрано с gcc3.*.

Поэтому, если у Вас до применения патча не работало, то этот патч скорее устраняет какие-то проблемы другие, но не по Gcc4.

Мне вообще то кажется, что два первых являются действительно патчами, один к драйверу, а другой к модулю ядра. А что касается третьего, то тут я затрудняюсь, но мне кажется, что можно вообще было без него обойтись. Т.е. может быть это для того, чтобы gcc4 как-то изобразил из себя gcc3. Да и то вобщем то неуклюже.

Ведь все равно приходится, как Вы пишите делать

cp libfglrx_ip.a.GCC3 libfglrx_ip.a.GCC4

А если взглянуть в инсталляционные скрипты для fglrx, то там есть строки, в которых четко видно, что имеет место проверка соответствия компилятора на котором собрано ядро и сравнение его что-то вроде с gcc2 и gcc3 (т.е. с компилятором на котором собиралсь сами драйвера).

Я предполагаю, что если Ваше ядро собрано на gcc3, а у Вас установлен gcc4, то это еще можно обойти. Для этого-то и предназначен последний патч (ну это ИМХО).

Но если Ваше ядро собрано на gcc4, вот тут-то и вопрос.

А не в том на самом деле, какой компилятор установлен в данный момент.

У вас может быть и gcc5 (главное, соответствие компилятора, на котором собрано ядро и компилято, на котором собраны эти бинарные драйвера от ATI).

ПОправьте, если не прав

С уважением АЛександр

8084
С уважением АЛександр

Ык вот уважаемы АЛександр, а почему же вы не пошли с этим вопросом в тему «Драйвера для видео hot radeon» ?

И использовать токо один, последний патч, т.к. он — unified,

а вот собсно и он http://www.openjlab.org/fglrx-linux-2.6.12-gcc4.diff

anonymous
Sasha2
…выкусено..

ПОправьте, если не прав

Поправляю вас уважаемый. Дистриьбутив у меня Suse 9.3 Pro. Стандартный компилятор 3.3.5 я заменил на 4.0.1. Соответственно им же скомпилировал ядро и драйвера также им, поэтому патч последний мне например просто необходим.

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

28084: Кстати уважаемый с вот этим как вы сказали unified у меня компилится, но потом вылетает с ошибкой, поэтому пользуюсь тройной связкой патчей и пока что они меня не подводили, хотя как было сказано во многих форумах стоит попробовать оба варианта и.

Sasha2

Честно говоря на то,что у Вас Gentoo меня навело на мысль вот это сочетание rc.

Хотя действительно, после того как я написал это иуже отправил я вспомнил, действительно ведь Gentoo устанавливается при помощи emerge, а не rpm.

Но вот, что касается SuSe 9.3, ту тут у меня большие вопросы.

1. Непонятно, как Вы пришли к такой схеме инсталляции? (На SuSe 9.3 у меня 8.14.13. устанавливается их штатными средствами и без всяких патчей).

2. Как Вы обошлись с модулем ядра, который предлагается SuSe для установки с 8.14.13? Т.е. Вы его тоже перекомпилировали? (Не думаю, так как исходников для него у Вас точто нет).

3. Скорее, как я уже сказал в предыдущем сообщении, что-то у Вас остлось от gcc3.

4. Ну и последнее такие проблемы возникают сейчас и у пользователей Mandriva (2006 Beta). Там тоже gcc4. А вот уж компания Mandriva (ну во всяком случае с эти дкайвером) подходит значительно более ответственно к этому вопросу. В этом дистрибутиве уже сам драйвер и ядро ставится на стадии инсталляции.

5. Ну а уважаемому 8084 отвечаю, что этим патчем я пользовался. В соответствии с какой-то рекомендацией с fedoraforum.org. Однако безуспешно.

6. БОлее того, я задал этот вопрос на Livna, и мне разработчики подтвердили, что жа, это пока проблема не полностью решена.

7. И еще раз хочу поблагодарить уважаемого Blackman за присланные патчи.

Ну чем черт не шутит, рискну еще раз.

Кстати на эти эксперименты с этим хозяйством убил уже 1.2 Gb из своего 2.0 Gb трафика на СТРИМЕ. Однако какая-никакая, а польза есть, достаточно хорошо все же разобрался со сборкой ядер.

anonymous

Отвечу на все вопросы по порядку:

1. и 2. Инсталляция была стандартной с той лишь разницей что Сюзиковский fglrx и модуль который шел отдельно либо не ставились вообще либо были убиты сразу после инсталляции вслед за ними отправилось и ядро. И в доверешение я выкинул компилятор 3.3.5. Отсюда следует ответ на вопрос 3. Остаться от gcc3 у меня ничего не может в принципе ссылки и прочее я сам корректировал. Вывод gcc -v

Target: i686-pc-linux-gnu
Configured with: тра ля ля
Thread model: posix
gcc version 4.0.1

4. Очень рад за Манжриву надеюсь х примеру последует и Novell, чтобы ничего не пришлось вырезать и править.

6. Помнится когда сам искал патчи находил очень забавный патч специально для Федоры 4ой и как говорилось на Livna лежит fglrx уже с данным патчем якобы решающем все проблемы. Видимо они ошибались.

7. Не стоит благодарности. Попробуйте сделать как я написал выше. Надеюсь что поможет. Эи патчи проверены на Мандриве 2005 и Сюзи 9.3.

Sasha2

К сожалению не помогло

anonymous
Sasha2
К сожалению не помогло

Очень жаль, но всё таки запостите для потомков какая ошибка то вылезла при sh make.sh

Sasha2

Да никакой не вылезло.

Все устанавливается нормально.

(Ну кстати и другие драйвера тоже нормально устанавливаются, в смысле схемы инсталляции, даже пробовал согласно Livna скачать исходники их драйвера и самому собрать модуль ядра — ничего сложного оказалось, 5, 6 команд и все оказалось собраным и удивительно, что и устанавливается прям как по их писаному, все без ошибок, система старует и все говорит, есть модуль ядра, правильный соответствующий ядру для этого fglrx).

Только 3D не работает. (Ну а для обычной работы ATI карт им и этот драйвер не нужен, нужен только нормальный модуль ядра).

Можеть быть тут уже даже не сами эти драйвера, а AGP виновато (т.е. вопрос надо ставить не fglrx+gcc4, а AGP+gcc4).

Но я не настолько опытен, чтобы раазобраться здесь.

ПРиходится подождать (может ATI скомпилирует свои драйвера под gcc4).

Немного отступая от темы: Для ATI даже по барабану, что там в xorg.conf написано (только бы мог запускаться как обычный VGA).

Вообще в логах для X вываливается что-то вроде AGP cannot be inited (ну вобщем как и при других схемах инсталляции).

А вот у меня тоже вопрос к Вам: у Вас новая карта (имеется ввиду модель больше 9600). Все дело в том, что для более старых карт (до 9600) это может быть действительно срабатывать. Они поддерживались еще, ну уж точно в RH9.0, в рамках самого дистрибутива.

Но у меня 9800XT, вот с ней действительно мороки хватало.

Хотя потом все начало обходиться.

В SuSe 9.1, 9.2, 9.3 все ставится влет (по их инструкциям).

В Mandriva (прямо на стадии инсталляции, а при обновлении ядра, исходников, на автомате даже и модуль ядра обновляется).

Даже в пресловутом Gentoo с его прибабахами по установке все работает как часы.

Ну вот первыый опыт gcc4.

Приходится констатировать, что ребята из Fedora не смогли в полной мере обеспечить совместимость этого компилятора с бинартными драйверами.

Сейчас такие же вопли по Mandriva и SuSe (Mandriva пока прямо пишет, что binary compatibilty with gcc4 broken till now, т.е. что пока в ее Beta 2006 нарушена бинарная совметимость из-за применения gcc4).

Что ж посмотрим, что получится у них.

anonymous
Sasha2
Да никакой не вылезло.

Все устанавливается нормально.

Лог Иксовый покажи особенно с того момента где ничинается загрузка fglrx и тогда посмотрим чего у тебя за ошибка.

Sasha2

Да это уже не имеет смысла.

Все дело все таки в AGP.

Да и многие патчи, о которых я читал, они используются в тех ситуациях, когда я устанавливаю этот драйвер без всяких проблем и без всяких патчей (ну например в FC3).

Буду ждать Мандрива или SuSe.

А в логе ошибка типа xf86_ENIVAL

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

Просто, начиная с 2.6.12 модуль agp в ядре переписан заново.

Вот и возникают проблемы.

P.S. Да кстати таких проблем сейчас вагон: имеется ввиду тех, кто также пользуется бинарными драйверами (ну например NVida, модемщики и т.д.).

Т.е. здесь кардинально прблему надо решать.

anonymous

А случаем не такая ошибка:

(EE) fglrx(0): [agp] unable to acquire AGP, error «„xf86_ENODEV“»

Sasha2

Нет точно не такая.

Sasha2

А вот строчка [agp] unable to acquire AGP также присутствует

anonymous
Sasha2
А вот строчка [agp] unable to acquire AGP также присутствует

А модули то загружены agpgart и чипсета ?

8084

в makefiel , что в 2.6.x папке, есть строчка — Dчето про ажп

Sasha2

Пясняю для 8084:

Все загружено и перепробовано во многих вариантах, а именно,

когда поддержка agp включается как модуль и поддержка чипсета 82875 также как модуля

КОгда поддержка agp включается в ядре (с вариациями поддержки 82875 в виде модуля или с включением в ядро).

Более того перепробовано на ядрах, начиная с 1368-FC4smp и до 1398-FC4smp.

При этом пробовалось как на исходных, так и пересобранных.

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

ТОлько не работает 3D.

Теперь для BlackMan

Далее строчка с ошибкой

(EE) fglrx(0): [agp] unable to acquire AGP, error «„xf86_ENODEV“»

присутствует в Xorg.0.log когда система только что установлена (т.е. когда вообще не установлено никаких драйверов для 9800XT — и это нормально: точно такая же строчка будет и в тех дистрах, где установка драйвера от ATI еще не произведена, т.е. карта работает, с ней все в порядке, но нет 3D, описание этой ошибки дано на сайте ATI, так что эта вообщем-то и не ошибка).

А вот моя ошибка типа xf86_ENOVILE представляет собой ошибку с кодом 1007, при этом является незадокументированной, т.е. т.е., кто писали драйвер, не могли предвидеть возникновение такой ситуации, но и как положено для ошибки с таким номером просто присвоили ей (в обработчике) такую сторку.

Еще раз говорю мне на Livna подтвердили, что это еще остается проблемой, пока не преодоленной.

Наверно, когда написали этот драйвер, его опробовали на картах не позднее модели 9600.

А вот для более поздних моделей — эта оказалось не рабочим.

8084

А добавить строчку в xorg.cong

В секцию device

Option «UseInternalAGPGART» «yes»

Пробовал?

8084

О себе: У меня эта ошибка с enodev была с патчами присланными blackman-ом, ну а с USE_THIS_PATH, избавленном от изменения makefile все на ура с ядреным agpgart

Sasha2

Еще раз поясняю, такие вещи как UseInternalAGP=yes или no абсолютно по барабану.

От этих багов драйвера от ATI избавлены еше ну по моему в какой-то 8.10.* версии.

Если драйвер не устанавливается, то это не помогает никак.

А если он установился правильно и работает, то это также ни на что не влияет (поверьте, что проверял на своем опыте).

Строчка эта по всей видимости осталась из прежних версий программы (и конфигуратора тоже) (которые вероятно для всех версий драйверов от ATI одни и те же).

8084
Строчка эта по всей видимости осталась из прежних версий программы (и конфигуратора тоже) (которые вероятно для всех версий драйверов от ATI одни и те же).

да ни фи…

Патчил когда оригинальным usethispatch, он убирал из makefile вот эту строчку — -D__AGP__ \

В результате чего дрова собирались без поддержки ядренного agpgart, я делал — пользовать внутренний аджипижиарт, и работало 3d, такчто нифи.. им не по барабану.

Sasha2

Тогда модель карты назовите.

Я уже устал говорить, что на Интернете много случаев, когда люди что-то патчат. Причем описывают случаи такие, когда у меня все без патчей (штатными средствами) устанавливалось.

Ну для других вещей значит эти патчи.

Еслди говорите, что получилось, то тогда назовите:

1. Дистрибутив

2. Версия ядра

3. Версия gcc

4. Модель карты

8084

Mandriva 2005LE

2.6.13-rc6-ck

3.4.3-7mdk

R350 AP (radeon 9600)

anonymous
8084
О себе: У меня эта ошибка с enodev была с патчами присланными blackman-ом, ну а с USE_THIS_PATH, избавленном от изменения makefile все на ура с ядреным agpgart

:) У меня как раз наоборот. Работает со связкой патчей которые я тут уже приводил и всё. С USE_THIS_PATСH не работает как ни крути его.

Suse Linux 9.3

2.6.13-rc6-git4

4.0.1

RV 350 AP

2Sasha2: Работает с патчами и с более новыми картами.

Sasha2

В Mandriva 2005LE у меня 9800XT становится без всяких патчей с включенным 3D.

Не могу понять, уважаемый 8084, ну что Вы там патчите?

И еще раз карты до 9600 (включительно) отличаются от карт более высоких моделей, несмотря на то, что используется один и тот же драйвер.

Вообще карты до 9600 (включительно) поддерживаются самими дистрибутивами

9600 — это вообще то Radeon, а вот выше — это уже fglrx (т.е. FireGL).

Последние комментарии

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.