Архив рубрики: Uncategorized

Nvidia-drivers-430.14 segmentation fault

Прилетело обновление nvidia-drivers-430.14, поставил, перезагрузился, и вот она, консоль.

В Xorg.log такие записи:

[ 9.094] (EE) Backtrace:
[ 9.097] (EE) 0: /usr/bin/X (xorg_backtrace+0x4d) [0x557f6e1c6eed]
[ 9.097] (EE) 1: /usr/bin/X (0x557f6e014000+0x1b6de9) [0x557f6e1cade9]
[ 9.097] (EE) 2: /lib64/libpthread.so.0 (0x7efe2631c000+0x14e90) [0x7efe26330e90]
[ 9.097] (EE) 3: /lib64/libc.so.6 (memcpy+0x1f) [0x7efe261ee78f]
[ 9.097] (EE) 4: /usr/lib64/libnvidia-glcore.so.430.14 (0x7efe23972000+0x118a299) [0x7efe24afc299]
[ 9.097] (EE) 5: /usr/lib64/libnvidia-glcore.so.430.14 (0x7efe23972000+0x118a3fd) [0x7efe24afc3fd]
[ 9.097] (EE) 6: /usr/lib64/libnvidia-glcore.so.430.14 (0x7efe23972000+0xe73a48) [0x7efe247e5a48]
[ 9.097] (EE) 7: /usr/lib64/xorg/modules/extensions/libglxserver_nvidia.so (0x7efe21cb5000+0x8c2d32) [0x7efe22577d32]
[ 9.097] (EE)
[ 9.097] (EE) Segmentation fault at address 0x7efe22671008

Ребята на форуме нашли решение - выпилить флаг compat у nvidia-drivers.

 

Linux 5.1 и Nvidia Drivers 418.56

Обновился на днях до ядра 5.1, но драйвера Nvidia 418.56 не собираются с ядром 5.1, а версия 430.09 не работает, выбрасывает при загрузке граф. режима обратно в консоль, что в 5.0.12, что в 5.1.

Поэтому решил допилить 418.56 для работы с новым ядром. На просторах интернета нашёл такую статью, чел расписывает, как заставить 418.43 работать на 5.1-rc1, практически мой случай.

Перевод на русский 🙂

В файлы nvidia-drm-connector.c nvidia-drm-drv.c nvidia-drm-encoder.c nvidia-drm-gem-nvkms-memory.c в самый верх добавляем строчку #include <linux/version.h>

В файл /kernel/nvidia-drm/nvidia-drm-connector.c, примерно в 203 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
int drm_helper_probe_single_connector_modes(struct drm_connector
*connector, uint32_t maxX,
uint32_t maxY);
#endif

В файл kernel/nvidia-drm/nvidia-drm-drv.c, примерно в 37 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
void drm_kms_helper_poll_init(struct drm_device *dev);
void drm_kms_helper_poll_fini(struct drm_device *dev);
bool drm_helper_hpd_irq_event(struct drm_device *dev);
void drm_kms_helper_poll_disable(struct drm_device *dev);
#endif

В файл kernel/nvidia-drm/nvidia-drm-encoder.c, примерно в 33 строчку добавляем:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
void drm_kms_helper_hotplug_event(struct drm_device *dev);
#endif

и в строчку 161:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 1, 0)
/* Add header constants missing after 5.1-rc1 */
int drm_helper_probe_single_connector_modes(struct drm_connector
*connector, uint32_t maxX,
uint32_t maxY);
#endif

В файле kernel/nvidia-drm/nvidia-drm-gem-nvkms-memory.c (примерно 77 строчка) заменяем

static int nv_drm_vma_fault(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int nv_drm_vma_fault(struct vm_fault *vmf)
#else
static vm_fault_t nv_drm_vma_fault(struct vm_fault *vmf)
#endif

В файле kernel/nvidia-uvm/uvm8.c (примерно 176 строка) заменяем

static int uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)
#else
static vm_fault_t uvm_vm_fault_sigbus_wrapper(struct vm_fault *vmf)
#endif

и (примерно 515 строчка)

static int uvm_vm_fault_wrapper(struct vm_fault *vmf)

на

#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 1, 0)
static int uvm_vm_fault_wrapper(struct vm_fault *vmf)
#else
static vm_fault_t uvm_vm_fault_wrapper(struct vm_fault *vmf)
#endif

Вот и всё, модуль должен собраться. И да, по ссылке еще 2 файла были изменены - в kernel/common/inc/nv-list-helpers.h нужно поменять строку

static inline int list_is_first(const struct list_head *list,

на

static inline int nv_list_is_first(const struct list_head *list,

и файл kernel/nvidia-uvm/uvm8_range_tree.c, нужно поменять строку

if (list_is_first(&node->list, &tree->head))

на

if (nv_list_is_first(&node->list, &tree->head))

Но, это всё нужно делать для драйвера версии 418.43. Я лично это всё поменял, как было написано, компилятор начал ругаться на файл kernel/nvidia-uvm/uvm8_range_tree.c

error: implicit declaration of function ‘nv_list_is_first’; did you mean ‘list_is_first’? [-Werror=implicit-function-declaration]
if (nv_list_is_first(&node->list, &tree->head))
^~~~~~~~~~~~~~~~
list_is_first

Ну я и добавил в самый верх этого файла

#include "../common/inc/nv-list-helpers.h"

и всё прекрасно собралось. Но! После всего этого, я опять полез на сайт того чела и дальше вижу в Recent Post такое - фикс для драйвера версии 418.56. И там английским по белому написано, что для данной версии трогать файлы uvm8_range_tree.c и nv-list-helpers.h на предмет замен строк вообще не нужно. Такие дела 🙂

 

Linux и RTL8811CU

Приехал ко мне из Китая вот такой USB-адаптер на чипе RTL8811CU. Так как я заранее посмотрел, что драйвера для него под Linux есть, плюс умело заборол проблемы с предыдущим чипом от Realtek, больших проблем с его подключением не ждал.

Скачал дровишки отсюда https://github.com/whitebatman2/rtl8821CU, начал компилять, первый раз make ругнулся на файл rtl8821CU/os_dep/linux/rtw_android.c

ошибка: в макрос «access_ok» передано 3 аргументов, но используется только 2
if (!access_ok(VERIFY_READ, priv_cmd.buf, priv_cmd.total_len)) {
^
/home/alex/rtl8821CU/os_dep/linux/rtw_android.c:629:7: ошибка: «access_ok» не описан (первое использование в этой функции)
if (!access_ok(VERIFY_READ, priv_cmd.buf, priv_cmd.total_len)) {
^~~~~

Поэтому я её просто закомментил, раз access_ok не описан. И да, в С коммент строки - //, а не #.

Следующая ошибка была в файле rtl8821CU/os_dep/linux/ioctl_cfg80211.c

ошибка: implicit declaration of function «get_monotonic_boottime»; did you mean «getboottime»? [-Werror=implicit-function-declaration]
get_monotonic_boottime(&ts);
^~~~~~
getboottime

Здесь сам компилятор подсказывает, что get_monotonic_boottime нужно заменить на getboottime.

На этом всё, дальше компиляция проходит без проблем, модуль собрался и работает с ядром 5.0.11

Установка Wi-FI адаптера Mercusys MW300UM на чипе RTL8192EU

Предыстория — после 9 лет работы полетела встроенная сетевая карта на материнской плате. Печально. Нужно покупать новую и всё такое. Тут я вспомнил, что где-то у меня припасена сетевая карта, которую я покупал ещё 10 лет назад. Начал рыться в закромах, и вот она. Сдул с неё многолетнюю пыль, прочитал название — Dlink DFE-520.

Ок, попробуем. Воткнул, включил поддержку в ядре, карточка завелась. Но есть две не совсем приятные вещи — 1 — карта после выхода из сна не подхватывается, какие-то проблемы или с модулем или с самой картой. Ну и скорость. После гигабитной карты чувствуется задержка даже при переключении дорожек в плеере.

Поэтому посетила мысль — а не купить ли Wi-FI адаптер? Открыл свой любимый магазин электроники, начал выбирать. Выбор пал на Mercusys MW300UM, невысокая цена (гигабитная сетевая карта от DEXP стоит столько же, но почитав о чипе, который на ней стоит, перехотел брать), скорость в 300 Мб/с, и высокая мощность передатчика, плюс беспроводное соединение. Почитал про чип — RTL8192EU, в линуксе должен работать, даже судя по комментариям к адаптеру. Отправился в магазин, нашёл адаптер (осталось 2 коробочки), жадно схватил одну и метнулся на кассу. Заплатив бабло и получив чек (кстати, гарантия 3 года), на второй передаче понёсся домой.

Придя домой, предвкушал, что сейчас по быстрому воткну адаптер, ну максимум подключу модуль к ядру и всё будет кошерно. Но самое интересное было ещё впереди.

Итак, воткнув адаптер в комп, запустил lsusb, дабы глянуть, что же известно про этот адаптер. А собственно всего ничего, lsusb выдал вот это:

Bus 002 Device 005: ID 2c4e:0100

Ну ок, мы пойдём другим путём — полезем в гугль. Итак, гугл сообщает, что есть несколько вариантов — собрать модуль из ядра, либо скачать с гитхаба, собрать и присовокупить к ядру.

Конечно, проще собрать модуль самого ядра. Полез в ядро, подключил модуль RTL8XXXU и RTL8XXXU_UNTESTED. Собрал ядро, перезагрузился. Ничего. Модуль не загрузился. Сделал это вручную — всё равно тишина, устройство wlan0 не появилось. Dmesg конечно сыпет сообщениями, что типа устройство подключено, производитель такой-то и всё прочее, но это как-то не помогает обеспечить работу устройства.

Ну ладно, хорошо. Соберём и поставим сторонний модуль. На выбор есть 4 (на самом деле больше):

https://github.com/Mange/rtl8192eu-linux-driver
https://github.com/masterzorag/RTL8192EU-linux
https://github.com/jeremyb31/rtl8192eu-linux-driver
https://github.com/ZeeRooo/RTL8192EU

В общем общем после всех плясок выяснилось одно — в коде модуля нет нашего идентификатора устройства (2c4e:0100), поэтому, даже когда модуль загружался, он не работал с адаптером. Что нужно сделать, чтобы всё было прекрасно? Добавить строчку в исходники. Покажу на примере ядра — в моём случае это 5.0.3 и модуля, который я взял с https://github.com/ZeeRooo/RTL8192EU. И да, в некоторых репозиториях, например jeremyb31 и Mange есть возможность поставить модуль через DKMS, что актуально для пользователей Debian-подобных дистрибутивов.

Но хочу сказать сразу, после добавления в ядро идентификатора, устройство wlan0 появилось, ближайшие сети нашлись, но вот подключиться не получилось. В dmesg сыпались ошибки "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!" и невозможности аутентификации. Там же была почта, на которую просили написать про работу модуля, что я собственно и сделал, ждём ответа (если он вообще будет).

Итак, модуль ядра. Открываем файл (уже в каталоге с ядром, например /usr/src/linux) drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c и ищем в самом конце такие строчки, (должно быть заглавие #ifdef CONFIG_RTL8192E):

{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

0x2357, 0x0107 — это и есть идентификатор устройства. Добавляем туда такую строчку

{USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0100, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

0x2c4e, 0x0100 — это мы взяли из вывода lsusb.

Сохраняем файл, не забываем включить модуль rtl8xxxu и rtl8xxxu_untested и собираем ядро, теперь адаптер будет автоматом подхватываться ядром.

Сейчас соберём сторонний модуль ядра. Я бы рекомендовал качать с https://github.com/ZeeRooo/RTL8192EU, т. к. судя по логам он активно поддерживается.

$ git clone https://github.com/ZeeRooo/RTL8192EU.git

$ cd RTL8192EU

Редактируем файл os_dep/linux/usb_intf.c, в нём так же ищем строчки типа {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops}, под заглавием #ifdef CONFIG_RTL8192E, только здесь они практически в самом начале файла.

Добавляем туда нашу строку:

{USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0100, 0xff, 0xff, 0xff), .driver_info = (unsigned long)&rtl8192eu_fops},

Ну и дальше

$ make

# make install

Модуль будет называться 8192eu.

После установки модуля, для его загрузки нужно выполнить modprobe 8192eu, или вытащить и вставить адаптер.

И да, если используется сторонний модуль, ядерный модуль (rtl8xxxu) должен быть выгружен и наоборот.

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

Размытие (блюр) экрана Kwin и Firefox при включённых эффектах

Тут давеча решил подключить эффекты Kwin (они же свистелки и перделки), а то чё как не пацан, с деревянными окнами без анимации.

Включил, всё прекрасно, окна красиво сворачиваются-разворачиваются-свертываются и все такое, вот только в Firefox поплыл шрифт, стал очень сильно размытым. Отключал сглаживание, хитинг-хуитинг и прочее - как криво было так и осталось. Плюс если перед уходом в suspend был открыт Youtube c видео, при выходе из suspend'a Firefox  просто очень криво отображал страницу, вплоть до чёрного экрана с какими-то элементами страницы. Решение было такое - пересобрать Лису без флага hwaccel. Теперь всё нормально работает. Но тут мигнул свет.

Свет мигнул, а компьютер не перезагружался уже больше полумесяца. И вот, кеды загрузились и я вижу на экране вот такое. Путём поиска нашёл (каламбур, да) тему на KDE'шном форуме (картинку я взял оттуда же, ага) - нужно в Nvidia-settings отключить FXAA.

Патч (patch) для nvidia-drivers-340.106

В портежах появилась новая версия драйвера nvidia-drivers-340.106, который также успешно не собирается на ядрах 4.15.х, как и nvidia-drivers-340.104. Но патч для nvidia-drivers-340.104 не подойдет, нужен другой.

Ругань при компиляции такая:

/var/lib/dkms/nvidia/340.106/build/uvm/nvidia_uvm_lite.c:857:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.fault = _fault,
^~~~~~
/var/lib/dkms/nvidia/340.106/build/uvm/nvidia_uvm_lite.c:857:14: note: (near initialization for 'uvmlite_vma_ops.fault')
/var/lib/dkms/nvidia/340.106/build/uvm/nvidia_uvm_lite.c:887:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.fault = _sigbus_fault,
^~~~~~~~~~~~~
/var/lib/dkms/nvidia/340.106/build/uvm/nvidia_uvm_lite.c:887:14: note: (near initialization for 'counters_vma_ops.fault')

Патч доступен по ссылке, действия аналогичны.

Убираем тиринг (tearing) на Nvidia в Linux

Как начал пользовать драйвер от Nvidia за номером 340.106, заметил, что появился тиринг в Firefox и просмотре фильмов через mplayer. Решение такое - добавить в файл xorg.conf такую строчку в секцию Screen (а можно и в Device, так же будет работать):

Option "metamodes" "nvidia-auto-select +0+0 { ForceCompositionPipeline = On }"

Если строка Option "metamodes" уже есть, то нужно просто добавить "nvidia-auto-select +0+0 { ForceCompositionPipeline = On }" в конец этой строки.

Можно и через nvidia-settings:

nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceCompositionPipeline = On }"

Но это на только на текущую сессию, без добавления в xorg.conf при перезагрузке всё вернется взад, зато после ввода команды действие наступит сразу же, можно будет проверить, пропадёт тиринг или нет, а после этого уже вносить изменения в xorg.conf.

Ядро Linux 4.15 и Nvidia драйвера версий 384.98 и 340.104

В общем обновился я на ядро ветки 4.15. Но с этим ядром не собираются nvidia-drivers 340.104.

Для решения этой проблемы идём по этой ссылке и скачиваем патч для драйвера Nvidia и распаковываем его из архива.

А вот что нужно сделать, чтобы наложить патч. Запускаем пересборку nvidia-drivers, причём делать это нужно на новом ядре или чтобы символическая ссылка /usr/src/linux указывала на директорию с ядром 4.15. Т.е. обновили ядро и следом нужно запустить пересборку nvidia-drivers (хотя после каждого обновления ядра это и так нужно делать). Ждём, когда вылетит ошибка, примерно такая:

/var/calculate/tmp/portage/x11-drivers/nvidia-drivers-340.104/work/kernel/nv.c: In function ‘nv_start_rc_timer’:
/var/calculate/tmp/portage/x11-drivers/nvidia-drivers-340.104/work/kernel/nv.c:2407:5: error: implicit declaration of function ‘init_timer’ [-Werror=implicit-function-declaration]
     init_timer(&nvl-;>rc_timer);
     ^~~~~~~~~~
/var/calculate/tmp/portage/x11-drivers/nvidia-drivers-340.104/work/kernel/nv.c:2408:28: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
     nvl->rc_timer.function = nvidia_rc_timer;
                            ^
/var/calculate/tmp/portage/x11-drivers/nvidia-drivers-340.104/work/kernel/nv.c:2409:18: error: ‘struct timer_list’ has no member named ‘data’
     nvl->rc_timer.data = (unsigned long) nvl;
                  ^
cc1: some warnings being treated as errors

Переходим в каталог  /var/calculate/tmp/portage/x11-drivers/nvidia-drivers-340.104/work/ (у меня установлены nvidia-drivers-340.104) и копируем туда же патч.

Накладываем его такой командой (от рута, естественно):

patch -p0 <nv_patch_340.104_linux_kernel_4.15

Дальше просто продолжаем сборку, с помощью команды ebuild, про неё подробней можно прочитать здесь.

ebuild /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-340.104.ebuild compile install qmerge clean

 

 

 

О предыдущем посте

В предыдущем посте я писал, что на некоторых ядрах не цеплялись NFS шары, ошибки в файловой системе и т.д.

В обчем, дело обстоит так.

По поводу NFS. Когда я перезагружал Cubietruck, чтобы загрузить новое ядро, он работал уже какое-то время, и в файловой системе на жёстком диске появились ошибки. Cubietruck перезагружался, диск монтировался, запускалась проверка на наличие ошибок. Проверка проходила успешно, но службы, которые используют данный винт, нужно было после проверки обязательно перезапустить, иначе они не работали. Как например NFS сервер - клиенты просто не могли к нему подключиться. Или тот же Transmission-daemon -  он запускался, но все раздачи были остановлены. Или MiniDLNA не отдавал список файлов - BubbleUPnP видит Cubietruck, цепляется к нему, видит список директорий, но они все пустые.

Итак, с этим всё понятно, дело не в ядрах 😉

Т.е. всё нормально бы цеплялось на всех ядрах, если бы не лезли ошибки в файловой системе. Остаётся решить, кто же здесь виновник - файловая система, или может жёсткий диск сам по себе уже начинает разваливаться.

Я писал, что были ошибки именно файловой системы и ещё ошибки от модуля UAS (USB Attached SCSI), примерно вот такие. Полез я почитать, что же это за модуль такой. На сайте linux-sunxi есть статья о нём. Вкратце, что пишут - это чуть более быстрый протокол доступа к HDD и SSD, является опциональной частью спецификации USB 3.0, но может работать и с USB 2.0, если железа и драйвера совместимы. Ниже идут тесты чтения/записи, с включённым и выключенным модулем UAS. Когда он выключен, время чтения примерно 35 МБ\с, скорость записи 33-34 МБ\с. Когда он включён, скорость чтения около 40 МБ\с, скорость записи 37-38 МБ\с.

Но есть ещё одна деталь - на порт подаётся 900 миллиампер в час, а не 500. И как пишут дальше, из-за этого возможно такая ситуация, что 2,5" жёсткий диск не сможет даже раскрутиться.

Так что я выпилил этот модуль из ядра. Cubietruck работает почти 6 суток, dmesg молчит, никаких ошибок файловой системы.