Как установить AMD Crimson на 64-разрядную версию Arch Linux?
Я пытался установить последние драйверы AMD на мою Linux-машину, но после компиляции меня приветствует следующее сообщение:
modprobe: ОШИБКА: не удалось вставить 'fglrx': неизвестный символ в модуле или неизвестный параметр (см. dmesg).
Пожалуйста, обратите внимание, что я не слишком хорош в этом вопросе о Linux, потому что я больше родом из BSD.
Ситуационные детали
- Arch Linux, x86_64, выпуск 2016.01.01
- Версия ядра: 4.3.3-2
- AMD Radeon R9 290x
- Малиновый, fglrx 15.302
Сделано
В начале сценарий установки даже не доходил до лицензионного соглашения, потому что мне пришлось установить kernel-headers
пакет. В этот момент я действительно мог начать пытаться установить его.
Просто запуск скрипта дал мне ошибку:
/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:634:9: error: void value not ignored as it ought to be
len = seq_printf(m, "%d\n", major);
^
После небольшого поиска я нашел это решение и выполнил его вручную. /usr/lib/modules/fglrx/build_mod/make.sh
Но компиляция закончилась этим сообщением:
WARNING: "mtrr_add" [/usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko] undefined!
WARNING: "mtrr_del" [/usr/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko] undefined!
Конечно, вы должны игнорировать предупреждение, и поэтому я приступил к установке только скомпилированных модулей... что привело к сообщению:
modprobe: ОШИБКА: не удалось вставить 'fglrx': неизвестный символ в модуле или неизвестный параметр (см. dmesg).
Посмотрев на dmesg, я вижу следующие строки:
[ 2848.332722] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[ 2848.332725] Disabling lock debugging due to kernel taint
[ 2848.343063] fglrx: Unknown symbol mtrr_del (err 0)
[ 2848.343114] fglrx: Unknown symbol mtrr_add (err 0)
Некоторые поиски привели меня к следующему сообщению: https://patchwork.ozlabs.org/patch/510277/ котором упоминается удаление mtrr_add()
на основании того, что это как-то плохо
Крестовый поход по замене mtrr_add() на независимую от архитектуры arch_phys_wc_add() завершен, это обеспечит использование преимуществ объединения с записью (PAT на x86) вместо использования MTRR. После завершения крестового похода скрыть прямой доступ MTRR для водителей.
Итак, что мне теперь делать?
Я понятия не имею, как поступить на этом этапе? Должен ли я быть в источнике, ища функции, используя mtrr_add
а также mtrr_del
? Есть какой-то патч, который я должен применить? Это просто большой провал, и я должен сдаться?
1 ответ
Благодаря комментариям Daniel B получилось.
Итак... что мне нужно было сделать, это перейти на более старую версию ядра /xorg и убедиться, что она придерживается (несмотря на то, что Arch Linux разрабатывался, чтобы оставаться на переднем крае). Но это было немного сложно.linux-4.2.5-1
Поскольку я застрял в консоли, я вручную загружал более старые пакеты из архива (в частности: linux-4.2.5-1, linux-headers-4.2.5-1 и xorg-server-1.17.4-2). Мне также пришлось получить старую версию группы пакетов xorg-drivers. Я поместил эти пакеты в /var/cache/pacman/pkg/
а затем понизил их с командой pacman -U /path/to/package-file.pkg.tar.xz
,
А потом переустановил Багровый драйвер и запустил aticonfig --initial
чтобы получить xorg.conf.
Чтобы обновление системы не выдумало, я добавил эти две строки в /etc/pacman.config
:
IgnorePkg = linux linux-headers xorg-server
IgnoreGroup = xorg-drivers
Эти строки будут генерировать предупреждения при запуске pacman -Syu
... так что ты не сможешь забыть об этом. Когда выйдут новые драйверы AMD Crimson, я смогу временно отключить этот драйвер.
А потом взорвалась...
После запуска pacman -Syu
и перезагрузка что-то пошло не так (при перезагрузке застряла инициализация). Я не совсем уверен, что случилось, но я сделал следующее:
- загрузиться с install-usb
- сделать
arch-chroot
в моем основном разделе - отключить SDDM
- перезагружать
- переустановите Crimson и восстановите xorg.conf
- включить SDDM
Это исправило это. Что я почерпнул из чтения различных журналов: после обновления fglrx
модуль снова портит ядро, что приводит к сбою Xorg, что, в свою очередь, делает невозможным доступ systemd-logind к SDDM. И как любая разумная часть ОС, systemd просто блокировал все (клавиатура не отвечала).