Identyfikacja i testowanie sprzetu PC pod Linuksem - Forum - LinuxPortal.pl window.___gcfg = {lang: 'pl'}; (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = '../../../apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })(); var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-21433029-1']); _gaq.push(['_trackPageview']); _gaq.push(['second._setAccount', 'UA-893508-4']); _gaq.push(['second._trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();
(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "../../../connect.facebook.net/pl_PL/all.js#xfbml=1&appId=222436117797494"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk')); Linux, open source, Android, ... Przyłącz się / Zarejestruj się | Zaloguj się | Archiwum wpisów z LinuxDlaFirm.pl oraz LinuxPraca.pl. Kategorie: Archiwum wpisów z LinuxDlaFirm.pl oraz LinuxPraca.plWiadomości PRASA LINUXKONKURSYOPINIEPODSTAWYZASTOSOWANIAPLIKI RPMOPISY DYSTRYBUCJIOPISY PROGRAMÓWSPRZĘTWIADOMOŚCI - LINUX DYSTRYBUCJEWIADOMOŚCI PROGRAMYPRAWOOPISY WDROŻEŃWiadomości o wdrożeniach systemu LinuxBlog LinuxDlaFirm.plWiadomości Linux dla FirmWiadomości o szkoleniachInformacje z rynku pracyNewsy ProgramyWiadomości - wydarzeniaMEDIA NIE LINUKSOWEBlog - archiwum








Identyfikacja i testowanie sprzętu PC pod Linuksem

Wizytówka Autora:

Magazyn LINUX+


sobota, 12 listopad 2005






Spis treści artykułu Identyfikacja i testowanie sprzętu PC pod Linuksem Część druga artykułu Część trzecia artykułu

Strona 3 z 3
Klawiatura i myszka
Choć są to najtańsze urządzenia, sprawdzenie ich nie zaszkodzi. Wystarczy
w tym celu uruchomić w środowisku graficznym programik xev. W
efekcie pojawi się puste okienko, ale na konsoli, z której go
uruchomiliśmy, będą pojawiać się informacje o każdym naciśnięciu
jakiegokolwiek klawisza na klawiaturze oraz o każdym – nawet
najmniejszym – ruchu myszką. Naciskanie klawiszy myszki
również będzie odnotowane, ale mogą być problemy z testowaniem
myszek z wieloma klawiszami czy rolkami. Pamiętajmy tylko, aby
okienko programu xev było cały czas aktywne.






Rysunek 6. Przy pomocy narzędzia Xev można łatwo sprawdzić, czy jakiś klawisz na klawiaturze nie jest zepsuty

Karty dźwiękowe
Karta dźwiękowa – jeśli nie jest całkowicie niesprawna –
powinna pojawić się na wyniku działania polecenia lspci.

Raczej trudno będzie nam znaleźć jakąś kartę dźwiękową nie działającą pod
Linuksem, więc przy pomocy większości dystrybucji Live będzie
można przeprowadzić szybki test jej działania. Przykładowo, w
Knoppiksie czy Linux+ Live po uruchomieniu komputera
możemy wydać polecenie cat /proc/asound/cards, aby zobaczyć,
czy nasza karta została rozpoznana. Przy pomocy komendy aplay -l
powinniśmy również zobaczyć listę wszystkich urządzeń, które mogą
odtwarzać dźwięk. Najlepiej testować równocześnie tylko jedną kartę
– dystrybucje Live bardzo często nie radzą sobie z
konfigurowaniem dwóch kart dźwiękowych w komputerze.

Gdy nasza karta jest widoczna w systemie, przy pomocy programu alsamixer
ustawiamy głośność, odszukujemy jakiś plik wav (np. komendą
find /usr -name '.wav') i wydajemy komendę aplay
plik.wav. Aby przetestować więcej wyjść karty równocześnie,
możemy posłużyć się wielokanałowymi plikami wav, dostępnymi
np. pod adresem
ftp://ling.lll.hawaii.edu/pub/greg/Surround-SDL-testfiles.tgz .
Komenda aplay -D plug:surround51 chan-id.wav umożliwi nam
przetestowanie wyjść i prawidłowości podłączenia sześciu głośników.

Karty sieciowe
Oczywiście, kartę sieciową można przetestować dopiero po podłączeniu do
działającej sieci. Poleceniem /sbin/ifconfig sprawdzamy, czy
nasza dystrybucja aktywowała interfejs sieciowy i czy ma on adres
IP. Połączenie z innym komputerem w sieci TCP/IP możemy oczywiście
sprawdzić poleceniem ping [adres_ip]. Pakiety tracone w sieci
lokalnej świadczą zawsze o błędach okablowania lub sprzętu. Za zgodą
administratora naszej sieci lokalnej możemy spróbować „potopu”
pingów. Da się go wywołać (z konta roota) poleceniem
ping -f [adres ip]. Przy sprawnej sieci nie powinno pojawić
się na terminalu wiele kropek, a w końcowym raporcie liczba
traconych pakietów powinna wynosić 0% lub 1%.

Aby testować sieć przy większym obciążeniu ruchem, przydatny może być prosty program
Nepim, dostępny pod adresem http://www.nongnu.org/nepim/ .
Do zbudowania ze źródeł (poleceniami cd src, make)
wymaga on biblioteki liboop-dev. Będziemy musieli uruchomić
go na dwóch komputerach-- na pierwszym (np. o adresie IP
192.168.1.1) wydajemy polecenie nepim, a na drugim nepim
-c 192.168.1.1 -d lub nepim -c 192.168.1.1 -d -u, jeśli
interesuje nas przepustowość udp, zamiast tcp.

Pozostałe urządzenia
Przy pomocy komendy lspci -v uzyskamy listę wszystkich urządzeń w
szynie PCI. Na wykazie będą oczywiście nie tylko urządzenia
umieszczone w poszczególnych złączach PCI, ale również te
zintegrowane z płytą główną. Jeśli oglądamy jakiś używany komputer,
zastanawiając się nad jego zakupem, zapewne szczególną uwagę będziemy
chcieli zwrócić na kontroler IDE. Przykładowo, u mnie jest on opisany
linią:

IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus
Master IDE

Jeśli ten opis dla kogoś nie jest szczególnie informacyjny i pomocny,
wrzucenie całości lub jego fragmentów do wyszukiwarek internetowych
powinno zaowocować szybkim znalezieniem specyfikacji technicznej
tego urządzenia. Podobnie jest w przypadku kontrolera USB –
u mnie pojawia się wpis USB 1.1 Controller [UHCI], więc wiadomo od razu, czego można oczekiwać
po urządzeniu.

Testy kontrolera IDE przeprowadziliśmy niejako „przy okazji” sprawdzania
dysków czy napędów optycznych. W przypadku kontrolera USB testowanie
jest już znacznie trudniejsze – dobrze byłoby posiadać jakieś
urządzenia, umożliwiające intensywną wymianę danych, np. flash dysk
– wtedy łatwo jest przesłać wiele megabajtów danych po
magistrali USB, upewniając się tym samym, co do jej działania.

Jeśli jesteśmy już przy magistrali USB, dobrze jest wiedzieć, że każde urządzenie
podpięte do niej – niezależnie, czy jest obsługiwane przez
Linuksa, czy nie – powinno pokazać się na wyniku działania
komendy lsusb -v. Jeśli nie możemy go tam znaleźć, to jest
ono po prostu zepsute.

W Linuksie listę wszystkich urządzeń, które alokują przerwanie systemowe (IRQ), otrzymamy
poleceniem cat /proc/irq. Podobnie otrzymamy listę portów
poleceniem cat /proc/ioports. W niektórych dystrybucjach
znajdziemy programy, które te listy drukują w nieco czytelniejszej
formie, np. lsdev czy procinfo. Na tych listach
znajdziemy jednak tylko urządzenia, które działają w systemie,
podczas gdy np. lspci pokaże wszystkie urządzenia w
magistrali, także te nie używane przez nas.

Jeśli uważamy, że jądro nieprawidłowo przydzieliło przerwania jakimś urządzeniom lub szukamy wszelkich
możliwych rozwiązań, aby poprawić działanie naszego komputera, możemy
spróbować kilku parametrów jądra, które zmienią domyślne sterowanie
przerwaniami. Są to m.in. acpi=noirq, pci=routeirq,
noirqbalance oraz biosirq.

Zakończenie
Opisane tutaj metody na pewno pozwolą nam uzyskać sporo informacji na temat
dowolnego komputera, działającego pod kontrolą Linuksa. Ktoś może
zauważyć, że te same informacje – a czasami nawet większą ich
ilość – można uzyskać przy pomocy jednego programu, np. KDE
Informacja o systemie, czy podobnego. Gdy jednak nauczymy się
wydobywać informacje, korzystając z danych w /proc, będziemy
mogli dowiedzieć się więcej o każdym komputerze, nawet jeśli nie
mamy zainstalowanego KDE, albo dostęp do niego uzyskujemy wyłącznie
poprzez ssh.






Rysunek 7. Zamiast posługiwać się linią komend, te same informacje o sprzęcie możemy uzyskać przy pomocy programu KDE Informacje o Systemie

Podobnie, jeśli chodzi o testowanie sprzętu – wiele można wykonać przy pomocy
prostych uniwersalnych narzędzi, dostępnych w każdej dystrybucji.
Zapewne dlatego dla Linuksa nie powstaje za wiele wyspecjalizowanych
programów do testowania sprzętu. Bardzo ciekawym programem,
sprawdzającym równocześnie procesor, pamięć RAM i pamięć masową,
jest Stress (http://weather.ou.edu/~apw/projects/stress/ ).
Przy jego pomocy można uruchomić równocześnie trzy procesy
sprawdzania procesora, dwa procesy sprawdzania procedur
wejścia/wyjścia, jeden proces sprawdzający pamięć RAM (ograniczając
się do 128 MB) oraz jeden proces sprawdzający zapis na dysku pliku
wielkości 3 GB (w katalogu bieżącym). Wszystko to z ograniczeniem do
30 sekund. Właściwa składnia polecenia w tym przypadku wygląda
następująco: stress -c 3 -i 2 -m 3 --vm-bytes 128M -d 1
--hdd-noclean --hdd-bytes 3G --timeout 30s.


Niezależnie jednak od tego, czy stosujemy wyspecjalizowane narzędzia do testowania poszczególnych
elementów, czy programy w rodzaju Stress, powinny one
bezbłędnie wykryć uszkodzenia krytycznych elementów naszego
komputera. Pamiętajmy o tym, aby na serio potraktować ostrzeżenia o
możliwości przegrzania procesora uzyskane przy pomocy programów w
rodzaju BurnK7. Zabezpieczenia przed przegrzaniem, oferowane
przez BIOS płyt głównych, są tutaj szczególnie pomocne.



Bezpieczne testowanie
Testowanie procesora i pamięci, a nawet twardego dysku, powoduje wydzielanie
się dużych ilości ciepła. Niejako przy okazji, stanowi również spore
wyzwanie dla zasilacza w komputerze oraz stabilizatorów napięcia na
płycie głównej. Dlatego bardzo dobrze podczas testowania sprzętu
zapewnić sobie dostęp do czujników temperatury płyty głównej i
procesora oraz mierników napięcia.

Najpopularniejszym oprogramowaniem do monitorowania czujników sprzętowych jest zestaw
modułów jądra i programów użytkowych z projektu Lm_sensors.
Więcej informacji na temat jego konfiguracji można znaleźć w Linux+
z czerwca 2005 roku. Spośród dystrybucji typu Live można go
znaleźć w StressLinux lub w dołączonej do tego numeru Linux+
Live.

W StressLinux– jeśli naszej płyty głównej nie znajdziemy na liście,
pojawiającej się przy starcie dystrybucji – możemy spróbować
uruchomić program sensors-detect i załadować moduły jądra,
których lista pojawia się na końcu działania tej komendy. Następnie
– zgodnie z instrukcją – wydajemy komendę cp
/etc/sensors/sensors.conf /tmp/. Wtedy prawidłowy odczyt z
czujników powinien się pojawiać na konsoli 12 ([ctr]+[alt]+[f12]).

W Linux+ Live, po przeprowadzeniu rozpoznania czujników przy pomocy sensors-detect,
powinna wystarczyć komenda /etc/init.d/lm_sensors restart.
Odczyt z czujników możemy zobaczyć przy pomocy polecenia Sensors
lub programu Ksensors.

Wygodniejszym od Lm_sensors bywa program Mbmon, który możemy ściągnąć z
http://www.nt.phys.kyushu-u.ac.jp/shimizu/download/download.html .
Co prawda, obsługuje on nieco mniejszą ilość sprzętu i działa
wyłącznie z konta roota, ale do swojego działania nie wymaga
żadnych modułów jądra – po prostu uruchamiamy program ./mbmon
i wyniki odczytów są co kilka sekund drukowane na konsoli. Czasem
nie wszystkie są prawidłowe, np. bywają dwukrotnie zawyżone
napięcia, ale i tak program sprawdza się bardzo dobrze, gdy chcemy
zaobserwować jakieś nagłe zmiany czy niebezpieczne wahania
temperatur.

Czujniki temperatury występują również wewnątrz twardych dysków. Dostęp do nich pod Linuksem możemy
zapewnić sobie przy pomocy programu Hddtemp
(http://www.guzu.net/linux/hddtemp.php ). Wystarczy polecenie
hddtemp /dev/hdc, aby zobaczyć, jaka temperatura panuje
wewnątrz urządzenia. Maksymalna temperatura, w jakiej może pracować
urządzenie, jest zawsze podawana przez producenta w jego
specyfikacji technicznej.

Niestety, hddtemp będzie działać tylko z dyskami IDE. W przypadku dysków SATA do jego
działania byłyby potrzebne łatki na jądro z eksperymentalnymi wersjami libata.




W Internecie:
- Strona domowa dystrybucji StressLinux:
http://www.stresslinux.org/

- Programy Mbmon oraz Xmbmon:
http://www.nt.phys.kyushu-u.ac.jp/shimizu/download/download.html

Program do testowania procesorów i pamięci Cpuburn:
http://pages.sbcglobal.net/redelm/

Program Stress do testowania wielu elementów równocześnie:
http://weather.ou.edu/%7Eapw/projects/stress/

Narzędzia umożliwiające odczyt danych S.M.A.R.T.:
http://smartmontools.sourceforge.net/

Informacje o testach, jakimi poddawane są nowe wersje jądra Linuksa:
http://www.osdl.org/docs/stabilization_plan.current .



Artykuł z Magazynu Linux+ nr 10/2005 .
<< Poprzednia - Następna strona







Drukuj

Powiadom znajomego


















Komentarze: 1















Pawel


Gość
, dn. 26 sie 2006


















Identyfikacja i testowanie sprzetu PC pod Linuksem



#1176




TO WĄTEK DYSKUSJI O: : Identyfikacja i testowanie sprzetu PC pod Linuksem Bardzo ciekawy artkuł.











Zaloguj się aby dodać odpowiedź.











KONKURS!Dodaj WIADOMOŚĆ lub ARTYKUŁ Dziennikarz LinuxPortal.pl miesiąca stycznia 2012r. Dodaj wiadomość lub artykuł i zdobądź dowolną książkę z oferty wydawnictwa helion.pl. Menu: Strona główna Wiadomości Artykuły Konkursy Linux dystrybucje Programy Firmy Usługi Oferty pracy Szkolenia Kalendarz Forum | Kanały RSS | Archiwum wpisów | Blog LinuxPortal.pl | Kontakt do Redakcji Copyright 2003 - 2011, LinuxPortal.pl