Kategoria: Linux

Opublikowane w

Fujitsu Siemens Esprimo V6515

Staremu laptopowi (Asus A6U) się umarło, więc wymieniłem mojej miłej notebooka. Stanęło na tanim, tytułowym FS Esprimo V6515. Poniżej szybkie wrażenia z krótkiego użytkowania sprzętu i instalacji Debiana w wersji Lenny.

Fujitsu Siemens Esprimo V6515

Źródło: http://gdgt.com/fujitsu-siemens/esprimo/mobile/v6515/

Może Asusowi nie zmarło się tak całkiem, ale praca była niemożliwa – twierdził, że się przegrzewa i się wyłączał. Losowo. Szybka poprawa chłodzenia nie pomogła (a raczej pomogła na chwilę), poza tym sprzęt średnio nowy i średnio rozwijalny (Sempron 3000+, 512 MB RAM, dysk IDE), więc stanęło na tym, że szybciej i pewniej zmienić, niż naprawiać (czym i tak pewnie się zajmę), bo może płyta walnięta, czujnik jakiś czy procesor, a nie po prostu chłodzenie. Pojawił się więc nowy, względnie tani lapek.

Tytułowy FS Esprimo V6515, to: matowa matryca (to IMO plus) 15,4″, 2 GB RAM (1 GB + 1 GB dołożony), Nvidia 8200M, procesor Intel Pentium Dual Core T3400 (2,16 GHz), dysk 160 GB (5400 rpm), nagrywarka DVD. W porównaniu z poprzednikiem, na oko – demon szybkości. Z Windows Vista Basic w markecie już za 1350 zł brutto, czyli niedrogo, nawet porównując koszt modernizacji/naprawy poprzednika.

Pierwsze wrażenie – ogór. Nie ma nic, raptem 3 złącza USB, ethernet, wyjśnie na zewn. monitor, jakieś słuchawki i… tyle. Żadnej kamery, modemu, dodatkowych złącz, slotu na karty. Nic. Do tego tandetnie i delikatnie wyglądający plastik. Całość duża – gruby (wysoki), szeroki i głęboki. Wagę przemilczę. No cóż, low end… Ale że ma to być „przenośna stacjonarka”, a nie laptop, to w sumie jakość nie jest aż tak ważna, podobnie jak czas pracy na baterii.

Zadecydowała cena (chyba jedne z najtańszych laptopów w ogóle) i grafika z CUDA, którą mam zamiar kiedyś się pobawić bardziej. Krótko – do jakości można przywyknąć, a szybkość faktycznie jest OK (pamięć RAM współdzielona z grafiką). Sprzęt nie kupowany z myślą o Linuksie, bo nie będzie to podstawowy system na nim, ale na oko powinno działać, zresztą „jakoś to będzie”.

Na pierwszy ogień – zaraz po instalacji Windowsa – poszedł memtest – błędów nie było. Spróbowałem uruchomić Knoppiksa z USB i… pierwszy zawód. Nie zadziałał. Standardowe wyłączenie acpi itp. również nie pomogły.

Podejście drugie to LiveUSB Debiana Lenny w wersji 64 bit (DIY). Działa. I jest szybki. Bardzo szybki. Nie wiem, czy to kwestia 64 bit, czy samego sprzętu, czy uruchamiana z pendrive’a, ale KDE uruchamia się błyskawicznie. Szybka instalacja po kabelku ethernetowym (karta bezprzewodowa nie działa z liveCD) i… Lenny średnio się nadaje na desktop. Przynajmniej dla tej maszyny.

Przy standardowej instalacji (znaczy się Lenny postawiony debootstrapem, nie z użyciem instalatora) nie działały: wireless, klawisze specjalne (głośniej, ciszej, jaśniej, ciemniej) oraz… dźwięk. No dobrze, być może dźwięk działał, bo coś tam cichutko szumiało, tylko nie zauważyłem wyciszonego suwaczka od „speakers”. Działała akceleracja 3D (sterownik binarny Nvidii z dystrybucyjnego repozytorium) i karta ehernetowa, przy czym grafika zmieniała jasność na maksimum (a klawisze nie działały).

Jeśli chodzi o wireless, to lspci wskazało, że jest to Atheros AR242x 802.11abg, czyli całkiem zacna karta (nie spodziewałem się wsparcia dla 802.11a w takim low endzie). Szybkie sprawdzenie i… wiki Debiana stwierdza, że na kernelu z Lenny’ego ta karta nie zadziała (choć ogólnie powinna działać i to na sterowniku z jądra). No dobrze, i tak nie lubię dystrybucyjnych kerneli. Szybkie ściągnięcie waniliowego 2.6.32.6, ponieważ nie mam czasu, to nie bawię się w tuning, tylko biorę konfig z Lenny’ego, make oldconfig, make-kpkg –initrd kernel_image, reboot i… WiFi działa, ale – zgodnie z przewidywaniami – grafika nie bardzo.

Module assistant nie zrobi pakietu na podstawie sterownika z Lenny’ego, bo kernel za nowy. Nic to, zaczyna się backportowanie. Instalacja źródeł nvidia-glx i nvidia-kernel-source z repozytorium unstable (wersja 190.53-1), kompilacja, instalacja i… działa (przy okazji wrzuciłem mój ulubiony wicd dla WiFi, także backportowany). Dla odmiany, zamiast jasności na maksimum, jest na minimum. Wspominałem, że klawisze specjalne (nadal) nie działają? Za to działa:

echo "5" > /sys/class/backlight/acpi_video0/brightness

Ale da się pracować. 😉 Do tego szybkie zrobienie dynamicznej zmiany taktowania procesora (bez problemu).

Z podstawowych rzeczy został dźwięk. Stwierdziłem, że albo opcje do modułu potrzebne, albo nowsza alsa. Albo jedno i drugie. Alsa backportuje się bez problemu, trochę nt. opcji modułu (i – nie ukrywajmy – wielu innych rzeczy) znalazłem na opisie instalacji Lenny’ego dla V6505 (nieco inny sprzęt, ale wiele zbieżności). Po instalacji alsy odkrywam wyciszony suwak „speakers”. Nie wiem, czy go wcześniej nie zauważyłem, czy go nie było. W każdym razie po zwiększeniu głośności dźwięk działa.

Ostatecznie stanęło na tym, że klawisze specjalne nie działają, reszta działa (ww. strona sugeruje, że Ubuntu 9.10 obsługuje wszystko od kopa, więc jak komuś zależy na bezproblemowej instalacji Linuksa, to raczej tę dystrybucję polecam, choć jej nie testowałem).

Co do samego sprzętu, to uwagę zwraca także duży pobór prądu – powertop pokazuje, że zużywa dużo więcej prądu, niż HP Compaq 8430 sprzed 2,5 roku. Mówiąc dużo więcej, mam na myśli przynajmniej jakieś 30% (IIRC). Oba na podobnych ustawieniach – bez obciążenia (minimalne taktowanie), mało uruchomionych programów, włączone wifi, ekran o normalnej jasności. Natomiast jeśli chodzi o szybkość, to nie chodziło o bootowanie z pendrive’a – nadal jest bardzo szybki. Ikonki w splashu KDE robią pyk-pyk-pyk i system gotowy do działania. Bez żadnego tuningu.

Podsumowując – całkiem fajny sprzęt (IMO lepszy wybór, niż kupno typowego desktopa, jeśli ktoś nie ma jakichś wielkich wymagań dla np. grafiki), nawet obsługiwany przez Linuksa, choć Debian Lenny nie jest dla niego najszczęśliwszym pomysłem – wymaga rzeźby (a mimo to klawisze specjalne nadal nie działają). Przy czym należy mieć na względzie, że to nie mój sprzęt i raczej nie miałem czasu na wgryzanie się i zabawę.

Na potrzeby serwisu Linux on Laptops popełniłem opis instalacji Debiana Lenny na Fujitsu Siemens Esprimo V6515 (ang.) – może się komuś przyda. Więcej szczegółów dotyczących sprzętu, konfiguracji i instalacji pakietów – tamże. Ew. aktualizacje opisów uruchamiania także będą się znajdowały raczej tam, niż w tym miejscu.

Opublikowane w

Root tylko do odczytu (flash)

Trochę czasu minęło, odkąd pisałem o kluczu USB jako partycji root i tylko do odczytu. Oczywiście, jak się spodziewałem, nie wyczerpałem tematu i parę rzeczy wyszło w praniu.

Pierwsze – i w sumie najważniejsze – co wyszło – po przemontowaniu / w RW, instalacji nowych pakietów – nie daje się przemonotować w RO. Winnych było dwóch – blkid.tab oraz usunięte pliki nadal używane przez proces.

Szczęśliwie w trakcie poszukiwań rozwiązania, jak zrobić root tylko do odczytu, wpadłem na ReadonlyRoot na Debian Wiki, gdzie opisane jest, co zrobić. W przypadku blkid.tab należy zrobić symlinka i ustawić zmienną środowiskową. W przypadku używania usuniętych plików – zrestartować odpowiednie serwisy (polecenie checkrestart z pakietu debian-goodies). Poza tym, skorzystałem z patentu na mtab.

Na koniec potwierdzenie pierwszego spostrzeżenia – jest stabilnie. Bez UPSa 14 dni było.

Opublikowane w

Jak bezpiecznie korzystać z uszkodzonej pamięci RAM bez BadRAM.

BadRAM był fajny, ale jest nieutrzymywany. Ostatnią działająca u mnie wersja była do kernela 2.6.25.x, późniejsze, choć istniały (np. dla 2.6.29; dead link), to nie udało się ich – wbrew wcześniejszej radości – zmusić do poprawnego działania – nadal pojawiały się błędy np. na liczeniu sum kontrolnych.

Winny w tej maszynie jest ewidentnie RAM, co zostało już dawno stwierdzone, ale maszyna na tyle niekrytyczna, że inwestować się nie opłaca (poza tym, szkoda środowiska), a ze starszym (tj. 2.6.25.x) kernelem spokojnie i poprawnie działa. Poza tym, przecież to Linux, więc da się poprawić. I jaki uroczy temat do notek jest. 😉 Z okazji świątecznej wizyty w domu, postanowiłem jednak zerknąć, czy nie pojawiły się patche BadRAM do jakichś nowszych kerneli (serii 2.6.3x, znaczy).

Nie pojawiły się, ale zamiast tego, trafiłem na pierwszej stronie wyników na sposób radzenia sobie z uszkodzoną pamięcią pod Ubuntu, który w ogóle z BadRAM nie korzysta. Chwilę później trafiłem na ten wpis (dead link). Okazuje się, że za pomocą parametrów, które można przekazać kernelowi, w szczególności mem=XX oraz memmap=X$YY, można wyłączyć obszary pamięci z użytkowania, co przekłada się w praktyce, na możliwość bezpiecznego korzystania z uszkodzonej i dotychczas powodującej błędy pamięci. Więcej o parametrach w kernelowym Documentation/kernel-parameters.txt, ale na potrzeby tego zagadnienia wystarczą te dwa.

Pierwszy parametr (mem=) ogranicza wykorzystaną pamięć. Jeśli uszkodzenie jest w okolicy 312 MB (memtest+ prawdę powie), to mem=310M co prawda obniży dostępną pamięć do 310 MB, za to system będzie działał bez problemów. Tyle tylko, że stracimy 200 MB pamięci. Trochę sporo, zwłaszcza, jeśli całość do dyspozycji to tylko 512 MB.

Drugi (memmap=) jest ciekawszy, bo rezerwuje X pamięci od adresu YY. Przykładowo memmap=10M$305M oznaczy pamięć od  305 MB do 315 MB jako wykorzystaną. Czyli stracimy raptem 10 MB, a zyskamy niezawodny system. Tyle teorii. W praktyce na dystrybucyjnym 2.6.26 z Lenny’ego, mem=300M działało poprawnie (najprościej sprawdzić przez free -m), natomiast memmap=10M$305M był radośnie olewany – nadal pokazywało dostępną całą pamięć.

Przyczyny tego stanu rzeczy nie udało mi się ustalić (podejrzewam limit 4GB zamiast 1GB, błąd w kernelu lub korzystanie z initrd – jeśli ktoś zna odpowiedź, to proszę o info), natomiast skompilowanie własnego 2.6.32.2 na podstawie konfiga od 2.6.25.x (z którego spatchowanego BadRAM korzystałem do tej pory) rozwiązało problem – memmap=2M$311M, czyli wyłączenie tylko 2 MB spowodowało, że system działa poprawnie.

Ponieważ najłatwiej zaobserwować błędy było dotychczas na sumach kontrolnych, to testowanie wykonałem prostym skryptem (brzydki bash napędzany perlem – pewnie dałoby się prosto przespisać na gołego basha, ale kto tam ma czas…; skrypt na końcu wpisu). Stosunkowo duży plik (większy, niż dostępna pamięć RAM, mój tworzony przez dd if=/dev/urandom of=random.dat bs=1MB count=1024), z losową zawartością (tworzony raz, bo czasochłonne), liczenie sum kontrolnych. Jeśli błąd pojawi się w buforze dyskowym, to przy braku wielkiego pecha suma kontrolna będzie się różnić przed i po skopiowaniu. Zapuszczone w pętli, z logowaniem do pliku – nawet przy uszkodzonej pamięci nie wystarczy 1 przebieg – błąd nie pojawia się za każdym razem. Natomiast choćby jeden błąd oznacza, że coś jest nie tak jak być powinno.

Podstawą jest jednak free -m. Jeśli on nie widzi mniej pamięci, to można nie zaczynać nawet ze skryptem.

Jeśli po dłuższym teście brak błędów (pojedynczy błąd oznacza, że nie jest dobrze), to wystarczy dopisać linię do konfigu gruba, by przy każdej aktualizacji kernela dodawał do parametrów określony argument:

#kopt=root=/dev/hda2 ro memmap=2M$311M

Dzięki temu możemy korzystać z dowolnej (najnowszej!) wersji jądra, bez upierdliwego patchowania (cóż, patche badram były dość kijowe, włączenie z tym, że zdarzało im się mieć literówki uniemożliwiające kompilację).

Na koniec wspomniany skrypcik:

#!/usr/bin/perl
$src="/random.dat";
$dst="/tmp/memtest_tmp.dat";
$log="memtest_copy.log";
if (-f $dst){
   system (" rm $dst ");
}
system (" date >> $log ");
while (1){
  system (" cp $src $dst ");
  $res = `md5sum $dst`;
  $res2 = `sha1sum $dst`;
  $res_ = `md5sum $src`;
  $res2_ = `sha1sum $src`;
  $check = "ERROR";
   if (($res == $res_) && ($res2 == $res2_)){
     $check="OK";
   }
 system (" echo \"$check $res $res_ $res2 $res2_ \" >> $log ");
 system ("rm $dst");
}

Podsumowując: żegnaj BadRAM!