Tag: kernel

Opublikowane w

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 do podpięcia komputera 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.

MT7601U wg lsusb

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

Banana Pi

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… Bananian 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. 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.

Opublikowane w

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 dotyczącymi KVM i task blocked for more than 120 seconds:

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. Jedkal 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. Jedak 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 KVM task blocked, 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.

Opublikowane w

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?