Установка 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 молчит, никаких ошибок файловой системы.

Снова про обновление ядер Cubietruck и наболевшем Nouveau

Итак, сначала о Nouveau - после обновления ядра с ветки 4.9 на 4.14, фризы начали происходить чаще, что раздражает. Поэтому просто переехал на nvidia-drivers-340.04 (надо было сделать это с самого начала и не парить себе мозги), с которыми нормально работает и фреймбуфер и suspend2ram, плюс отличная производительность в играх.

Далее, про обновление ядер для Cubietruck. Ранее я писал, что пресобранные ядра не грузились, что возможно проблема в опции bootz заместо bootm и т.д.

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

Оно уже было собрано, версии 4.9.68. И я подумал - а почему бы не обновиться, на kernel.org уже лежало, если мне не изменяет память, 4.14.13. Скачал, подсунул конфиг от 68-го, всё прекрасно собралось. Но после перезагрузки выяснилось, что система не видит внешний жёсткий диск, т.е. даже не реагирует на его подключение. Так же дело обстояло и флешкой. Насколько я понял, просто не подавалось питание на USB порты. Обновлял и старое ядро, которое ветки 4.9. Ставил и 4.9.77 и 4.9.80, всё работало, но внешние компьютеры просто не цеплялись к NFS шарам Cubietruk'a. Следом поставил версию 4.15.1, но собирал не со старым конфигом, а через опцию make ARCH=arm sunxi_defconfig.

Но стали возникать проблемы с файловой системой (EXT4) на жёстком диске, впрочем, они стали возникать еще со старыми ядрами. После проверки на бедблоки было написано, что бедблоков нет, smartctl говорит, что с диском всё нормуль, fsck проверяет диск, находит ошибки, исправляет, но через пару дней опять в логах появляются ошибки файловой системы.

Но тут стоит добавить - диск работал более 3-х лет в режиме 24/7, плюс файловая система на нём не проверялась. А проблемы начались, после внезапного отключения электричества, когда Cubietruck проработал больше 2-х месяцев без перезагрузок. Я больше склоняюсь к тому, что проблема именно в старой файловой системе. Как вариант - отформатировать винт, файлы музыки и фильмов лежат в торрент-клиенте, так что он их просто перекачает.

Возможно, на следующих выходных так и сделаю.

Nvidia GTX 660 + Nouveau + Nvidia-firmware

Не так давно я писал, что Nouveau фризит систему с картой GTX 660. И вот на днях я решил более подробно поискать про баги в связке nouveau + GTX 660. На форуме дистрибутива Fedora нашёл вот такой совет - нужно установить прошивку, вытащенную из проприетарного драйвера Nvidia. Хотя, это вроде как нарушает лицензию, но кому какое дело 🙂 И в Gentoo эта прошивка находится в портеже, что не может не радовать.

Итак, всё просто - устанавливаем nvidia-firmware, файлы будут находится в /lib/firmware/nouveau

Все команды нужно выполнять от root.

Эта запись говорит модулю ядра, что нужно использовать проприетарный бинарный блоб:

echo "options nouveau config=NvGrUseFW=1" | tee -a /etc/modprobe.d/nouveau.conf

Далее подготавливаем конфигурационные файлы для Dracut, который будет создавать образ initramfs:

echo 'install_optional_items+="$(find /lib/firmware/{nouveau,nvidia} -printf "%p ")"' | tee /etc/dracut.conf.d/nouveau_firmware.conf

Пересборка initramfs для текущего ядра с изменениями в modprobe.d и включением прошивки:

dracut -f

Можно перезагружать систему.

Далее пишут, что не совсем победил фризы, но они стали намного реже. Хотя здесь сообщают, что установка прошивки решила проблему, но вылезла другая - пропадают чекбоксы, полосы прокрутки и т.д. в GTK3 приложениях. У меня всё нормально, он писал это практически 2 года назад, за это многое поменялось. В обчем, будем посмотреть.

Hearthstone и Wine

Смотрел я на Youtube всякое и на глаза попало видео о игре Hearthstone, что она такая интересная, замечательная и т.д. Я не слоупок, знаю, что она давно вышла, и видел летсплеи с ней, просто как-то не цепляло. Ну, думаю, надо установить, посмотреть, чем она так прекрасна. На Linux её не портировали, поэтому будем запускать через Wine.

И вот тут начинаются пляски. Я находил мануал от 2015-го года, но в нём ничего сложного не было - через winetricks установить wininet и в winecfg отключить библиотеку gbdhelp, а у библиотеки msvcp100 поменять значение на "сторонняя\встроенная".

Изначально я так и сделал, клиент Battle.net запустился, но при авторизации возникала ошибка под непростым названием BLZBNTBGS8000000B. Но клиент всё равно вроде как разрешал скачать игру. И ключевое слово здесь - вроде, т.к. после нажатия на кнопку "Скачать" выдавалось сообщение, что для игры нужна минимум Windows 7, а установлена XP. Ок, ребята, без проблем, поменял в winecfg XP на Windows 10. Перезапустил клиент, опять жму заветную кнопочку "Скачать". А мне говорят - тебе же сказали, что нужна минимум Windows 7, а у тебя установлена Windows 10. Вот на этом моменте меня начали терзать смутные сомнения насчёт того, что всё будет легко и просто. Раз игра так принципиальна, сменил операционную систему на Windows 7. Теперь-то ей деваться некуда, Windows 7, всё как положено. Но не тут-то было - у вас установлена Windows 7 Service Pack 1, а нужна Windows 7 как минимум. Вот такие дела.

Вооружившись Гуглом, приступил к поискам решения. Нашёл вот такую статью. Дальше будет что-то типа сжатого пересказа этой статьи с убиранием ненужных действий, например в статье и комментариях говорят, что нужно через winetricks поставить vcrun2015, corefonts и forcemono. Я их не устанвливал и всё прекрасно работает.

Сначала скачиваем клиент Battle.Net.

Обязательно нужен wine со staging, без него игра играться не будет.

Далее, для игры нужен 32-х битный префикс Wine. В комментариях к статье, пишут, что нужно удалить директорию .wine и создать заново. Этого делать точно не следует, т.к. пропадут все установленные Windows приложения. Проще создать отдельную директорию:

env WINEPREFIX=~/.wine32 WINEARCH=win32 winecfg

В Winecfg переходим на вкладку Staging и ставим все галочки, кроме последней, про Gallium (её может и не быть, как у меня). А на вкладке Библиотеки добавляем d3d11 и locationapi и отключаем их.

Объясняем Wine, что будем использовать для установки директорию .wine32

export WINEPREFIX=/.wine32

Переходим в директорию с установщиком Battle.Net и запускаем его:

wine Battle.net-Setup.exe

После установки клиента логинимся, скачиваем игру и играем.