5 V

Tak sobie myślę, że 5 volt czy też bardziej po polsku 5 woltów to byłaby dobra nazwa kategorii, albo i nawet bloga, gdyby ktoś chciał pisać więcej o drobiazgach zasilanych albo zasilających tym napięciem, czyli ogólnie gadżetach. Łapią się telefony, smartfony, różne SoC z ARM, ładowarki, powerbanki, osprzęt do komputera typu mysz, klawiatura czy słuchawki… Nie zauważyłem tego wcześniej, ale od dość dawna coraz więcej urządzeń zasilanych jest właśnie tym napięciem, choć niekoniecznie przy użyciu gniazd USB, i stało się ono w jakiś sposób znakiem naszych czasów.

Ostatnio poczyniłem, głównie w Chinach, parę zakupów spod znaku 5V właśnie. Po pierwsze, kupiłem miernik prądu na USB. Pokazuje napięcie i natężenie w zakresie odpowiednio 3,5-7 V oraz 0-3 A. Głównie z myślą o mierzeniu, ile prądu pobierają różne urządzenia peryferyjne podłączane do komputera, bo powertop wydawał się pokazywać wartości co najmniej dziwne (mysz w pracy 1W IIRC). Potem dowiedziałem się, że są rozwiązania ciekawsze, choćby z pomiarem pojemności, którego mi trochę brakuje (o tym później), ale to urządzenie robi robotę, a w sumie informacja o napięciu i natężeniu wnosi najwięcej.

Miernik prądu USB

Źródło: aukcja sprzedawcy na aliexpress.com

Szybko okazało się, że drugie (wg producenta pierwsze, bo miernik ma napis charger doctor, co dopiero teraz zauważyłem), co najmniej równie interesujące zastosowanie, to diagnostyka ładowarek. Mam taką jedną, tandeta wysokiej klasy, nie wiem jak do nas trafiła do domu. Szybko przestała działać, coś grzechotało w środku. Okazało się, że urwał się drucik od 230V idący do płytki. Przylutowałem. Nie wiem, czy drucik nie robi czasem za bezpiecznik, bo przewodnik w nim ma grubość włosa i ogólnie zastanawiam się, kto ten badziew do obrotu dopuścił… Wspomniana ładowarka ma jeszcze jedną „ciekawą” cechę – ładowane smartfony wariują. Testowane na dwóch różnych. Zachowują się, jakby ktoś naparzał w zablokowany ekran. Jeden cały czas, drugi tylko przy próbie korzystania z ekranu. Podłączenie miernika ujawniło podejrzanie niskie napięcie podczas ładowania, które prawdopodobnie jest przyczyną. No chyba, że jest kolejnym objawem „jakości”, a przyczyna to np. szybkie skoki napięcia… 😉

Skoro o ładowarkach mowa, w Biedronce są/były zestawy za 9,99 zł składające się z ładowarki sieciowej i samochodowej. Sieciowa niby 750mA, ale Banana Pi z kartą WiFi działa. Samochodowa też jest świetna, w porównaniu z jakąś chińską, którą miałem wcześniej. Wcześniejsza ładowała, ale bilans energii przy włączonym Yanosiku i niewygaszonym ekranie był ujemny (patrz wpis i komentarze). Na tej z Biedronki jest zdecydowanie dodatni, czyli ładowarka faktycznie ładuje.

Kolejny chiński zakup to powerbank. 5000 mAh, z ogniwem słonecznym (200 mA, więc raczej gadżet, ale od biedy…). Nawet wydaje się działać, trochę nie mam pomysłu jak sprawdzić rzeczywistą pojemność. Na razie ładuję telefon, który ma baterię 1160 mAh. W godzinę naładował od 25% do 86%, więc nieźle. Zobaczę, ile razy naładuje telefon. Wynik będzie trochę zafałszowany, bo powerbank leży na biurku i twierdzi, że się ładuje od słońca, mimo braku bezpośredniego nasłonecznienia. Lepszego pomysłu na sprawdzenie pojemności chwilowo nie mam.

Po konkrety odsyłam na bloga o pomiarach energii, gdzie wkrótce pojawi się kategoria 5V i dokładniejsze dane dla poszczególnych urządzeń.

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.

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.