Uruchomienie karty Wi-Fi Mediatek MT7601U na Banana Pi

Jakiś czas temu kupiłem małe, tanie karty USB Wi-Fi w Chinach. Stwierdziłem, że przydadzą się do niewyposażonych we wbudowane karty płytek z ARM, czy nawet żeby któryś komputer podpiąć na szybko do sieci Wi-Fi w standardzie N. Karty przetestowałem na szybko na laptopie i wszystko było fajnie, ale… uruchomienie ich wymagało rzeźby i dokompilowania modułu. Dla jasności: chodzi o karty, które sprzedawane są jako Mediatek MT7601U USB bgn WiFi dongle.

Po podłączeniu w wyniku lsusb widać:

Bus 002 Device 002: ID 148f:7601 Ralink Technology, Corp.

 

a wymagany driver dla tej karty to mt7601u. W momencie podłączania karty USB w dmesg pojawia się:

[ 1075.027898] usb 2-1: new high-speed USB device number 2 using ehci-platform
[ 1075.189356] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
[ 1075.196330] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1075.203764] usb 2-1: Product: 802.11 n WLAN
[ 1075.208160] usb 2-1: Manufacturer: MediaTek

 

Dziś potrzebowałem uruchomić Banana Pi pod kontrolą dystrybucji Bananian z tą kartą, wetknąłem ją w lapka, żeby odświeżyć sobie budowanie modułu i… miło mnie zaskoczył – działało od kopa. Stwierdziłem, że może zasługa nowszego kernela (4.5), ale prawdopodobnie nie – brakujący firmware jest dostarczany w Debianie w pakiecie firmware-misc-nonfree. Niedostępnym w Jessie, ale nie jest to wielki problem. Poniżej krótka instrukcja, co zrobić, żeby zadziałało (dla Bananiana 16.04 (released 2016-04-23)). Być może zadziała także na starszym kernelu, ale nie testowałem. Zgodnie z tym, co piszą na GitHubie projektu, driver jest dołączony do mainline kernela, i opisany poniżej sposób powinen działać dla kerneli od 4.2 w górę.

Instalacja kernela z linii 4.x na Banana Pi (niezalecana w FAQ Bananiana, ale…):

wajig install linux-image-4.4-bananian

 

Następnie reboot, by Banana Pi działało z nowym kernelem. Kolejnym krokiem jest pobranie pakietu z firmware dla karty:

wget http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-misc-nonfree_20160110-1_all.deb

 

Usunięcie pakietów, które konfliktują z ww. pakietem (oczywiście wajig; wykonać dla wszystkich pakietów, które zgłoszą konflikt):

wajig remove firmware-ralink

 

Ostatnim krokiem jest instalacja pobranej paczki:

wajig install firmware-misc-nonfree_20160110-1_all.deb

 

Od tej pory karta USB Mediatek powinna po prostu działać po włożeniu do USB. Oczywiście należy połączyć się jeszcze z siecią bezprzewodową, ja polecam do tego wicd i wygodny konsolowy wicd-curses. Zadziała także dla Debiana w wersji stable (Jessie) – w zasadzie Bananian różni się tylko kernelem.

UPDATE Dobrzy ludzie słusznie donoszą, że firmware-misc-nonfree jest w repozytorium backports, więc instalacja jest prostsza – wystarczy dodać stosowne repozytorium do źródeł. Przyznaję, że nie sprawdzałem, bo jakoś mi się błędnie zakodowało, że ani armel, ani armhf nie są dostępne w backports.

KVM i task blocked for more than 120 seconds – solved

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa, niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami:

kernel: INFO: task XXX blocked for more than 120 seconds.kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo – potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana, ale w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn – pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało, ale przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu – widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt – problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi… Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów – wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że… to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej – góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce – a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i… trafiony, zatopiony – wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale… problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.

Boot once w GRUB

Czasami jest potrzeba, żeby uruchomić maszynę z danym kernelem, ale tylko raz. W przypadku niepowodzenia chcemy mieć uruchamiany z powrotem stary, sprawdzony kernel. Zwykle taka potrzeba pojawia się, gdy testujemy nowy kernel i nie mamy fizycznego (lub zbliżonego) dostępu do maszyny, a np. mamy pod ręką kogoś, kto w razie problemów niekoniecznie pomoże z debugiem, ale chociaż wciśnie reset. Dziś pojawiła się u mnie taka potrzeba, za sprawą dedyka pod Piwika i chęci zmiany kernela z nieco starego z OVH na dystrybucyjny.

Okazało się, że wypadłem z tematu. Ostatni raz miałem potrzebę jednorazowego uruchomienia kernela chyba w okolicach LILO jako używanego bootloadera. Nie pamiętam jak to dokładnie w LILO wyglądało, ale mam wrażenie, że było proste, intuicyjne (w końcu jeden konfig) i – przede wszystkim – dobrze udokumentowane.

Poszukałem chwilę i znalazłem polecenie grub-reboot, któremu jako parametr podaje się numer wpisu w /boot/grub/grub.cfg i które ma powodować jednokrotne uruchomienie kernela o podanym wpisie. Ucieszyłem się, że pomyśleli o mnie i tak prosto. Maszynka niekrytyczna, kernel dystrybucyjny, więc raczej wstanie, wydałem więc stosowne polecenie, następnie reboot i… system wstał! Ze starym kernelem.

Nawet niezbyt się zirytowałem. Po prostu odpaliłem testowego kompa w domu i zacząłem się bawić. Ustawiam numer wpisu, który ma się włączyć, reboot i… to samo. Dłuższa chwila szukania i znalazłem opis na niezawodnym wiki Arch Linux:

This requires GRUB_DEFAULT=saved in /etc/default/grub (and then regenerating grub.cfg) or, in case of hand-made grub.cfg, the line set default=”${saved_entry}”.

Jak na lata doświadczeń przystało, wyboru kernela nie pozostawiam przypadkowi i w moim /etc/default/grub były ustawione na sztywno numery kerneli do uruchomienia. Zmieniam na powyższe na testowej maszynie w domu, grub-reboot potem reboot i… wstał! Z nowym kernelem. Świat wydaje się piękny, więc reboot, by wrócić na stary kernel i… tak dobrze nie ma. Uruchamia się za każdym razem z nowym.

Nawet niezbyt się zirytowałem, po prostu rebootnąłem zdalną maszynkę na nowy kernel. Skoro dystrybucyjny to raczej wstanie. Stosowne zmiany, reboot i… maszynka wstała, z nowym kernelem, wszystko wydaje się działać. Misja zakończona, cel osiągnięty.

I tu byłby koniec wpisu, ale w międzyczasie zacząłem rozmowę na ten temat na kanale IRC #debian (@freenode). Tam dowiedziałem się o /boot/grub/grubenv i o tym, że może (będzie) się tak dziać, jeśli nie jest ustawione prev_saved_entry. I faktycznie, nie było. I dowiedziałem się, że można to ustawić wydając polecenie grub-reboot więcej, niż raz.

Czyli, żeby zrobić boot once dla GRUBa, trzeba kolejno:

  • ustawić GRUB_DEFAULT=saved w /etc/default/grub
  • grub-reboot <wpis, gdzie ma być default>
  • grub-reboot
  • sprawdzić /boot/grub/grubenv na wszelki wypadek
  • reboot

I pomyśleć, że przy LILO była to szybka edycja konfiga plus lilo dla wprowadzenia zmian w życie… Znaczny postęp poczyniliśmy! 😉

Skoro już wpis na tematy linuksowe… Archa nie próbowałem, ale ludzie (w tym jeden DD) chwalą. Bardzo dobra dokumentacja. Poza tym, jest taka inicjatywa jak debianfork.org. I cieszę się, że jest. Bo skoro Debian może mieć więcej niż jedną architekturę, więcej niż jeden kernel (tak kFreeBSD), to czemu nie miałby móc mieć różnych, równorzędnych demonów do startu usług?

Dostępne wszystkie kody źródłowe dla Banana Pi

Developerzy postąpili zgodnie z zapowiedziami i udostępnili wszystkie kody źródłowe do Banana Pi. Są pierwsze doniesienia na forum o sukcesach z akceleracją GPU oraz potwierdzenia, że karta sieciowa działa na 1 Gbps na otwartym sterowniku. Nieoficjalnie słyszałem o prędkościach 520 Mbits/sec i 697 Mbits/sec (iperf; zależy czy serwer czy klient na bpi). Jak widać więcej, niż maksymalna przepływność USB. Czyli Raspberry Pi ma się coraz bardziej czego obawiać.

Biorę się do klonowania repozytoriów. 😉

Jak uruchomić touchpad na Dell Vostro 3360 pod Linuksem

Dell Vostro 3360 to zacny sprzęt, z którego korzystam w pracy, chyba od roku. Trochę żałuję, że nie kupiłem go do domu, ale kupowałem wcześniej, nie byłem jakoś przekonany do 13″, no i cena też trochę wyższa. Okazuje się, że jak najbardziej taki ekran daje radę. W pracy korzystam z wersji z dyskiem SSD i procesorem i5. Na początku było więcej, teraz jest 4,5-5h na baterii, więc wynik bardzo przyzwoity – długie wypady pociągiem, serie spotkań w firmie czy przedłużający sie wypad do kolokacji mu nie straszne i nie ma potrzeby korzystania z zasilacza.

Vostro 3360 daje się zmusić do działania z Linuksem (opis co jak działa może kiedyś popełnię, ale wcześniejsze opisy na potrzeby Linux on laptops nie cieszą się zainteresowaniem, więc motywacja jest nikła), ale nie jest to sprzęt, w którym wszystko działa OOTB. Nawet więcej: dawno nie widziałem sprzętu wymagającej takiej rzeźby w celu uruchomienia Linuksa. Grymasił na wersję kernela, co objawiało się… zwisami systemu (nic ciekawego w logach nie znalazłem). Co ciekawe tylko pod Debianem, kumple pod Ubuntu z IIRC taką samą wersją kernela problemu nie mieli. Na debianowym 3.6 (wówczas z experimental) działało stabilnie, więc tak zostało.

Inne problemy to: touchpad (naciśnięcie obu klawiszy naraz domyślnie nie emuluje naciśnięcia środkowego klawisza, co jest standardowym pod Linuksem – i ukochanym przeze mnie – skrótem do wklej), dźwięk czy karta sieciowa Atheros (o dziwo miedź). Dźwięk z alsą z Wheezy’ego działa IIRC od kopa, więc można uznać problem za załatwiony. Zresztą uruchomienie wszystkich komponentów Vostro 3360 na Linuksie (Debian Wheezy) ładnie opisał Łukasz. Co ciekawe, kernel 3.7 powodował jakieś problemy, ale nie pamiętam, czy chodziło o stabilność, czy może o coś innego.

W każdym razie czasy się trochę zmieniły, 3.6 jakiś taki starawy już. Doszły mnie słuchy, że karta sieciowa powinna działać bez magicznych zabiegów pod kernelem 3.11. Postanowiłem sprawdzić. Faktycznie, wydaje się działać. A system pozostaje stabilny. Pozostał jednak problem z touchpadem, więc postanowiłem zrobić instrukcję dla nowszej wersji kernela i nowszych plików ze strony, bo takie się pojawiły.

Na początek smutna sprawa: kernel 3.11, a dokładniej jego pliki nagłówkowe wymagają gcc w wersji 4.8, a to oznacza wymianę połowy systemu ze względu na zależności. Albo konieczność skompilowania kernela samodzielnie (czego na potrzeby desktopa wieki nie robiłem). Wybrałem bramkę numer dwa.

Wchodzimy na http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/view i pobieramy plik psmouse-alps-1.3-alt.tbz.

Rozpakowujemy go (w /usr/src)

tar xvjf psmouse-alps-1.3-alt.tbz

Pobieramy debianowe źródło kernela

wajig install linux-source-3.11

I kopiujemy bieżący konfig (zakładam, że mamy uruchomiony kernel 3.11 z Debiana)

cp /boot/config-3.11-2-amd64 /usr/src/linux-source-3.11/.config

Kompilujemy i paczkujemy kernel oraz pliki nagłówkowe

cd /usr/src/linux-source-3.11
make-kpkg --append-to-version=-bpo-rozie --initrd kernel_image
make-kpkg --append-to-version=-bpo-rozie kernel_headers

Instalujemy utworzone pakiety

cd .. && wajig install linux-image-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb && 
wajig install linux-headers-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb

Kompilujemy i instalujemy odpowiedni moduł:

cd /usr/src/psmouse-alps-1.3 && ./alps.sh dkms_build_alps

Polecenie to automatycznie powoduje przeładowanie modułu psmouse, więc jeśli nie wystąpiły błędy, to od tej chwili wszystko powinno działać poprawnie, w szczególności naciśnięcie obu przycisków touchpada powinno wklejać zawartość schowka.

UPDATE: Prawdopodobnie da się prościej, o ile się nie jest ślepym. Wystarczy do sources.list dodać obsługę backportów dla Wheezy’ego:

deb http://http.debian.net/debian wheezy-backports main contrib non-free

i dostępne staną się kernele linux-image-3.11*… Cóż, kto nie ma w głowie, ma w… kompilatorze. Inna sprawa (i moje usprawiedliwienie!) to fakt, że nie tylko nikt nie zwrócił na to uwagi w komentarzach, ale nawet dwie osoby korzystają z mojego kernela.

UPDATE2: Wygląda na to, że od wersji 3.13 kernela nie potrzeba takich zabiegów. Przed chwilą zainstalowałem z debianowych backportów 3.13.5-1~bpo70+1 i… touchpad działa od kopa, bez kompilacji czegokolwiek.