2004.01_Lm_sensors i Smartmontools–czujniki naszego komputera_[Sprzet].pdf

sprzęt

Lm_sensors i Smartmontools

– czujniki naszego komputera

Piotr Wolny

w czujniki monitorujące pracę zasilacza

i wentylatorów oraz temperaturę: proce-

sora, płyty głównej i innych elementów.

Te dodatki kojarzą się często z amatorami overclocking'u,

dla których ważne jest stałe monitorowanie temperatury,

zwłaszcza procesora, zmuszonego do pracy ponad nomi-

nalne możliwości. Moda na o verclocking powoli przeminę-

ła, jednak czujniki w sprzęcie pozostały. Głównie dlatego,

że sens ich istnienia wykracza daleko poza wspomniane

wcześniej zastosowania, a okazują się być bardzo potrzeb-

ne, zarówno w profesjonalnych systemach, jak i w zwy-

kłych, domowych komputerach.

Oczywiście przeciętnemu użytkownikowi komputera

czy nawet administratorowi serwera nie jest potrzebna

wiedza na temat aktualnych napięć, temperatur i obro-

tów wentylatorów w systemie. Ważne jest, aby te wartości

utrzymywały się w normie. Czujniki pozwalają właśnie na

szybkie odnotowanie, gdy coś w systemie zaczyna odbiegać

od normy, a to umożliwia szybką reakcję zanim dojdzie do

całkowitego zniszczenia sprzętu. Najlepszym przykładem jest

oczywiście zacierający się wentylator procesora, co powinno

zostać odnotowane przez dwa czujniki (obrotów wentylatora

i temperatury procesora). Równie niebezpieczne są jednak

awarie zasilacza, które bardzo często objawiają się najpierw

poprzez zmiany wytwarzanych przez niego napięć.

Od samego sprzętu cenniejsze bywają dane. I tutaj pro-

ducenci dysków twardych również wychodzą naprzeciw

użytkownikom. Od dłuższego czasu nowe dyski twarde

wyposażane są w SMART – Self-Monitoring, Analysis

and Reporting Technology, co można przetłumaczyć jako

Technologia samokontroli, analizy i raportowania . Opro-

gramowanie dysków twardych wyposażonych w SMART

potrafi przetestować dysk, przewidując awarie, które

z dużym prawdopodobieństwem nastąpią w przyszłości.

Niejako ,,przy okazji'' dyski twarde również wyposażono

w czujniki temperatury i wielu innych parametrów pracy.

Dostęp do danych niektórych czujników możemy uzyskać

z poziomu BIOS- u komputera bądź przy pomocy narzędzi

Rysunek 1. Program Lmcgi wyświetla dane o sprzęcie na stronie

WWW

dla MS Windows , dostarczanych na ogół przez producen-

tów płyt głównych, chipsetów bądź dysków twardych.

W Linuksie czujniki na płycie głównej możemy odczy-

tywać przy pomocy oprogramowania Lm_sensors ( http://

www.lm-sensors.nu/ ), a informacje SMART dostępne są

dzięki programom z projektu Smartmontools ( http://smart-

montools.sourceforge.net/ ).

Czujniki płyty głównej

Producenci płyt głównych najlepiej znają swoje produkty,

więc są w stanie dostarczyć użytkownikom MS Windows

aplikacje, które działają dobrze z konkretnym sprzętem.

Inaczej jest w przypadku Linuksa – twórcy Lm_sensors

musieli sami napisać sterowniki do kilkudziesięciu różnych

układów, które odpowiedzialne są za odczyt i raportowa-

nie wartości z czujników, z płyt głównych dziesiątek pro-

ducentów. Niestety, stworzenie bazy wiedzy o wszystkich,

czy przynajmniej większości płyt głównych, która umożli-

wiałaby uruchomienie lm_sensors bez konieczności wcze-

śniejszej, pracochłonnej konfiguracji, przerasta możliwości

twórców tego projektu. Problem polega na tym, iż niemal

każda płyta główna różni się od innych nie tylko zastoso-

wanymi układami scalonymi, ale również sposobem inter-

pretacji odczytywanych danych. Użytkownik Linuksa musi

więc samodzielnie poradzić sobie z konfiguracją. Pomocą

w tym zakresie służy program sensors-detect , o którym

będzie mowa później.

O autorze:

Autor jest politologiem i pracuje dla www.wzz.org.pl.

Linuksem zajmuje się mniej więcej od czasów jądra 2.0.20.

Kontakt z autorem: autorzy@linux.com.pl.

styczeń 2004

W spółczesne płyty główne wyposażone są

lm_sensors

Za bezpośredni odczyt danych z czujników płyty głów-

nej odpowiada pojedynczy układ scalony. Pobrane dane

trafiają do systemu operacyjnego poprzez magistralę I2C

(lub SMBus ). Potrzebujemy zatem:

• moduł jądra, sterujący magistralą I2C;

Instalacja ze źródeł

Czeka nas obowiązkowa rekompilacja całego jądra Linuksa.

Najpierw będziemy musieli nałożyć na jądro specjalną łatkę

z najnowszą wersją I2C oraz poprawkami dla wszystkich ste-

rowników korzystających z magistrali I2C. Instalację przepro-

wadzamy więc w następujących krokach:

• ściągamy i rozpakowujemy źródła „oficjalnego” jądra

z www.kernel.org (najnowsza stabilna wersja w momencie

pisania tego artykułu to 2.4.22);

• ze strony http://delvare.nerim.net/i2c/ ściągamy „ uni-

fied patch for Linux 2.4.22 (i2c-2.8.1) ”, czyli łatkę na

jądro, zawierającą I2C w wersji 2.8.1, oraz poprawki we

wszystkich sterownikach, wykorzystujących I2C . Plik linux-

2.4.22-i2c-2.8.1.patch umieszczamy w katalogu /usr/src .

Jeśli będzie dostępna nowsza wersja jądra, musimy oczy-

wiście zastosować również odpowiednio nowszą wersję

łatki;

• nakładamy łatkę np. poleceniem cd /usr/src/

linux-2.4.22; patch -p1 < ../linux-2.4.22-i2c-

2.8.1.patch ;

• konfigurujemy i kompilujemy nowe jądro. Przy konfiguracji

jądra, w dziale Character devices wybieramy I2C support ,

zaznaczamy koniecznie – jako moduły – I2C support,

I2C device interface oraz I2C proc interface. Jeśli mamy

kartę telewizyjną, zaznaczamy również I2C bit-banging

interfaces . Nie zaszkodzi również, jeśli zaznaczymy – jako

moduły – również inne sterowniki z tego działu;

• uruchamiamy system na nowym jądrze, a następnie

ściągamy i rozpakowujemy plik lm_sensors-2.8.1.tar.gz :

tar zxfvp lm_sensors-2.8.1.tar.gz; cd lm_sensors-

2.8.1 ;

• w archiwum Lm_sensors nie ma skryptu configure , więc

możemy od razu wydać polecenie make . Jeśli jednak

chcemy zmodyfikować jakieś opcje kompilacji, możemy

ręcznie poprawić plik Makefile . Wszystkie opcje są w nim

dobrze udokumentowane. Niestety – z aktualną wersją

– nie można włączyć opcji nakazującej skompilowanie

programu sensord ;

• instalację kończą polecenie make install oraz urucho-

mienie programu mkdev.sh , który znajdziemy w katalogu

prog/mkdev dystrybucji źródłowej lm_sensors. Oczywi-

ście polecenia te wydajemy jako root.

Rysunek 2. Program Ksysguard, skonfigurowany do pokazania

zależności pomiędzy obciążeniem procesora a jego temperaturą

• moduł jądra, sterujący samym układem, do którego

podpięte są czujniki;

• plik konfiguracyjny /etc/sensors.conf , zawierający infor-

macje, jak tłumaczyć dane z czujnika na rzeczywiste

wartości.

Instalacja Lm_sensors

Większość dystrybucji Linuksa dostarcza pakiet Lm_sen-

sors , jednakże jego konfiguracja pozostaje w rękach użyt-

kownika.

W Mandrake 9.2 pakiet lm_sensors-2.8.0-4mdk możemy

zainstalować np. przy pomocy graficznego narzędzia do

instalacji pakietów. W Aurox 9.1 pakiet lm_sensors-2.6.5-

5.i386.rpm (niestety trochę starsza wersja) powinien zostać

zainstalowany razem z systemem, a jeśli tak się nie stało,

możemy znaleźć go na pierwszej płycie CD. Jeśli korzysta-

my z którejś z powyżej wymienionych dystrybucji, możemy

od razu przejść do części „ Konfiguracja Lm_sensors ”.

Debian Woody również dostarcza pakiety lm-sensors

(zawiera podstawowe programy narzędziowe) oraz lm-

sensors-source (z modułami jądra w postaci źródłowej).

W przypadku tej dystrybucji instalacja pakietów jest nieco

trudniejsza – chcemy postępować zgodnie z zasadami dys-

trybucji Debian. Po zainstalowaniu pakietów lm-sensors

oraz lm-sensors-source musimy rozpakować plik /usr/src/

lm-sensors.tar.gz i przy pomocy polecenia make-kpkg (z

pakietu kernelutils ) skompilować nowy pakiet z modułami

jądra: cd /usr/src/linux; make-kpkg --revision wersja1

modules_image . Oczywiście w /usr/src/linux muszą znajdo-

wać się źródła aktualnie używanego jądra i musimy użyć

tej samej wersji kompilatora gcc , która została użyta do zbu-

dowania jądra. Jeśli wszystko pójdzie dobrze, w katalogu

/usr/src/ znajdziemy pakiet Debiana z modułami jądra,

który instalujemy poleceniem dpkg -i <nazwa pliku.deb> .

Po tej operacji w systemie mamy cały szereg nowych modułów

jądra – zarówno dodatkowe moduły magistral I2C w katalogu

/lib/modules/2.4.22/kernel/drivers/i2c/busses , jak i moduły

dla poszczególnych układów scalonych sterujących czujnikami,

w katalogu /lib/modules/2.4.22/kernel/drivers/i2c/chips.

Dodatkowo, w systemie pojawia się m.in. program sensors

– prosta komenda umożliwiająca odczyt stanu czujników, oraz

sensors-detect – program ułatwiający konfigurację pakietu.

Koniguracja Lm_sensors

Następnym krokiem jest uruchomienie w konsoli – jako

root – programu sensors-detect . Spróbuje on załadować

różne moduły magistrali I2C oraz różne moduły obsługu-

www.linux.com.pl

sprzęt

jące same czujniki, aż znajdzie kombinację, która działa na

danym systemie. W czasie tego testowania zadaje on użyt-

kownikowi kilka pytań, proponując zawsze jakieś domyślne

zachowanie. Przy pierwszej próbie możemy swobodnie mu

zaufać, odpowiadając na wszystkie pytania naciśnięciem

klawisza [ Enter ].

Jeśli wszystko pójdzie dobrze, program na końcu swo-

jego działania wydrukuje, które moduły jądra są wymagane

do działania Lm_sensors. Wydruk ten ma postać gotowe-

go fragmentu skryptu, który należy dołączyć do któregoś

z plików uruchamianych przy starcie systemu. Na moim

systemie wyglądał on tak, jak przedstawiono na Listingu 1.

Program zapyta również o zgodę na zmodyfikowanie pliku

/etc/sysconfig/lm_sensors . Jest to dobry pomysł – w pliku

tym również znajdzie się lista modułów, które mają zostać

załadowane. Jeśli posiadamy dystrybucję Mandrake , to sam

plik /etc/sysconfig/lm_sensors wystarczy do automatycznego

ładowania modułów przy starcie, gdyż zawarty w tej dystry-

bucji skrypt /etc/init.d/lm_sensors po prostu przeczyta /etc/

sysconfig/lm_sensors i załaduje niezbędne elementy. W przy-

padku innych dystrybucji możemy po prostu dołączyć frag-

ment, podobny do tego z Listingu 1, do któregoś z plików

startowych, lub zastosować taki mechanizm, jak w Man-

drake . W tym drugim przypadku musimy z dystrybucji źró-

dłowej Lm_sensors skopiować plik prog/init/lm_sensors.init

do /etc/init.d/lm_sensors oraz oczywiście nadać mu prawa

wykonywalności i spowodować (np. jakimś edytorem SysV),

aby był wykonywany przy starcie komputera.

Rysunek 3. Program GKreelM potrafi m.in. pokazywać

temperaturę z czujników

Ładujemy więc wymienione wcześniej moduły i odczytuje-

my najpierw czujniki eeprom poleceniem: sensors eeprom-* .

W efekcie dostajemy jedynie mało użyteczne informacje na

temat zainstalowanych kości pamięci w systemie. Moduł ten

nie będzie nam potrzebny, więc możemy usunąć go z listy

ładowanych przy starcie. Następnie badamy kolejny układ:

sensors it87-*. Wynik działania tej komendy na moim

systemie zamieściłem na Listingu 2. Co prawda, na pierw-

szy rzut oka wydaje się, że wynik jest mało rozsądny (przy

ponad połowie wszystkich wartości pojawia się ALARM),

ale okazało się, iż jest to prawidłowy moduł jądra.

Modyikacje w /etc/sensors.conf

Program sensors na moim systemie zwrócił nieco dziwne

wyniki, więc warto przyjrzeć się konfiguracji w /etc/

sensors.conf . Jest to bardzo obszernie skomentowany plik,

który określa konfigurację kolejno dla wszystkich obsłu-

giwanych układów. Mnie w tym przypadku interesował

wyłącznie it87 .

Zauważyłem, iż BIOS mojego komputera w ogóle nie

pokazuje napięć ujemnych -5 i -12. Program sensors poka-

zywał w tym zakresie niedorzeczne wyniki, więc dosze-

dłem do wniosku, iż mój sprzęt nie potrafi ich prawidłowo

odczytywać. Podobnie zresztą z napięciem Stdby . Postano-

wiłem zignorować te napięcia, dopisując w /etc/sensors.conf

przy moim chip'ie linie:

Analiza otrzymanej koniguracji

Fakt, że program sensors-detect zakończył pracę z suk-

cesem, nie oznacza, że na pewno wszystko jest gotowe

i działa. Czekają nas pewne testy. Musimy sprawdzić, jakie

dane otrzymamy z każdego z układów, który został wykry-

ty przez sensors-detect . W moim przypadku – co widać

na Listingu 1 – były to tylko dwa układy: eeprom oraz it87 .

Program sensors-detect jest jednak daleki od doskonałości

i u niektórych użytkowników potrafi „wykrywać” znacznie

więcej układów niż rzeczywiście znajduje się w systemie.

Jeśli spróbujemy odczytać dane z układu, którego nie ma,

program sensors zwróci kompletnie niedorzeczne wyniki.

ignore in5;

ignore in6;

ignore in7;

Listing 1. Końcowy wynik działania programu sensors-

detect

Następnie zauważyłem, że napięcie 3.3V jest dwukrotnie

zawyżone. Tutaj pomocne okazały się komentarze w pliku

/etc/sensors.conf , które nakazują w takim przypadku „zako-

mentowanie” jednej linii, co też uczyniłem.

Kolejną rzeczą do poprawienia były odczyty obrotów

drugiego i trzeciego wiatraczka, których nie posiadam.

Należało więc dopisać linie:

#----cut here----

# I2C adapter drivers

modprobe i2c-viapro

modprobe i2c-isa

# I2C chip drivers

modprobe eeprom

modprobe it87

# sleep 2 # optional

/usr/local/bin/sensors -s # recommended

#----cut here----

ignore fan2;

ignore fan3;

Ostatnim niepokojącym zjawiskiem były za wysokie napię-

cia Vcore oraz +12. W tym przypadku użyłem woltomierza,

styczeń 2004

lm_sensors

aby je porównać. Okazało się, że sensors ma racje. Są

one za wysokie, więc czas kupić nowy zasilacz... Oczywi-

ście w takim przypadku można również odpowiednio „do-

stroić” /etc/sensors.conf, aby dana wartość była uznawana

za normalną i nie wywoływała alarmu.

Po każdej modyfikacji /etc/sensors.conf , aby zmiany

odniosły skutek, należy wydać polecenie sensors -s .

Ostatecznie więc, po zmodyfikowaniu /etc/sensors.conf,

wydaniu polecenia sensors -s oraz sensors , efekt jest

taki, jak na Listingu 3.

Samodzielne ustalanie posiadanego

sprzętu

A co zrobić, gdy wyniki z układów „wykrytych” przez

sensors-detect nie są użyteczne. Zapewne oznacza to,

że nasz układ lub magistrala I2C nie zostały rozpoznane

przez sensors-detect bądź nie są przez niego obsługiwane,

przynajmniej w wersji, którą posiadamy. W każdym razie,

musimy się dowiedzieć, jaki układ, odczytujący dane z czuj-

ników, posiada nasza płyta główna. Informację tę możemy

zdobyć z następujących źródeł:

Rysunek 4. Strona domowa projektu Lm_sensors

programu MS Windows , który wykonuje podobną

funkcję.

Gdy wiemy już, jaki układ posiadamy, na stronie http://

www2.lm-sensors.nu/~lm78/supported.html możemy spraw-

dzić, czy nasz sprzęt jest obsługiwany, a jeśli tak, to od

której wersji Lm_sensors . Warto odwiedzić również stronę

http://www2.lm-sensors.nu/~lm78/newdrivers.html , która

zawiera listę sprzętu, który dopiero będzie obsługiwany

przez przyszłe wersje oraz tego, do którego z różnych

powodów nie planuje się napisać sterowników.

• instrukcja płyty głównej może wymieniać nazwę

układu w swojej specyfikacji bądź w innym miejscu,

np. na diagramie opisującym konstrukcję płyty;

• możemy samodzielnie odszukać układ na płycie głów-

nej – jest to z reguły niewielki, kwadratowy scalak

o boku ok. 1-2 cm, a jego oznaczenie można porównać

z listą obsługiwanego sprzętu, zamieszczoną na stro-

nach projektu Lm_sensors ;

• na stronie http://mbm.livewiredev.com/mobolist.html

znajdziemy listę płyt głównych i ich czujników dla

Praktyczne użycie Lm_sensors

Oczywiście stan czujników można sprawdzać okazyj-

nie wydając polecenie sensors . Inną możliwością jest

użycie bardzo prostego programu Alarmwatch ( http:

//www.dakotacom.net/~donut/ ) . Potrafi on – działając w tle

– stale monitorować czujniki, aby w przypadku problemów

sygnalizować je dźwiękiem z głośnika systemowego lub/i

komunikatem w syslog'u . Instaluje się go bardzo prosto

– wystarczą polecenia ./configure; make; make install .

Do jego działania oczywiście najpierw musimy skonfiguro-

wać Lm_sensors . Gdy już to zrobimy i sensors nie pokazuje

żadnego alarmu, sprawdzamy wartość pliku /proc/sys/dev/

sensors/<nazwa chip-a>/alarms . Tę liczbę używamy jako

ignorespec w wywołaniu alarmwatch , które może wyglądać

następująco: alarmwatch -B 5 it87-isa-0290 61702. Opcja

-B5 oznacza sygnał dżwiękowy co 5 sekund, it87-isa-

0290 to pełna nazwa chip-a, która pojawia się po wydaniu

komendy sensors , a cyfra 61702 to w moim przypadku

ignorespec, który uzyskałem w sposób podany wcześniej.

Dla niektórych użytkowników ciekawym programem

może być LMCgi . Jest to skrypt Perla, który wyświetla infor-

macje z Lm_sensors na stronie WWW. Jego konfiguracja jest

bardzo prosta i sprowadza się jedynie do zmiany nazwy

chip-a w źródłach skryptu.

Większość użytkowników będzie zainteresowana

graficznymi nakładkami na Lm_sensors . Wśród nich

zapewne najpopularniejsze i najbardziej dostępne będą

K sysguard – Strażnik systemu KDE oraz GKrellM – przy-

stosowany bardziej do środowiska GNOME. Obydwie te

Listing 2. Wynik działania programu sensors przed

modyfikacją /etc/sensors.conf

# sensors it87-*

it87-isa-0290

Adapter: ISA adapter

Algorithm: ISA algorithm

VCore 1: +1.72 V (min = +1.42 V, max = +1.56 V) ALARM

VCore 2: +2.52 V (min = +2.40 V, max = +2.60 V)

+3.3V: +6.42 V (min = +3.12 V, max = +3.44 V) ALARM

+5V: +4.75 V (min = +4.72 V, max = +5.24 V)

+12V: +13.44 V (min = +11.36 V, max = +12.60 V) ALARM

-12V: -20.61 V (min = -12.63 V, max = -11.41 V) ALARM

-5V: -9.01 V (min = -5.28 V, max = -4.81 V) ALARM

Stdby: +1.88 V (min = +4.72 V, max = +5.24 V) ALARM

VBat: +2.03 V

fan1: 3199 RPM (min = 0 RPM, div = 2)

fan2: 0 RPM (min = 3000 RPM, div = 2) ALARM

fan3: 0 RPM (min = 3000 RPM, div = 2) ALARM

M/B Temp: +40°C (low = +20°C, high = +40°C)

CPU Temp: +38°C (low = +25°C, high = +45°C)

Temp3: +15°C (low = +25°C, high = +45°C)

www.linux.com.pl

sprzęt

GKrellM

możemy posłużyć się programami smartctl oraz smartd.

Można je znaleźć w większości dystrybucji Linuksa lub

ściągnąć z http://smartmontools.sourceforge.net/ .

Załóżmy, że dysk, o którym chcemy się dowiedzieć

więcej, to /dev/hda . Komenda smartctl -i /dev/hda poin-

formuje nas, czy nasz dysk wspiera SMART, oraz czy jego

obsługa jest włączona. Jeśli jest wyłączona, możemy ją akty-

wować komendą smartctl -s on /dev/hda . Na początek

możemy zapytać dysk o jego stan:

Najbardziej rozbudowaną aplikacją graficzną, służącą do moni-

torowania systemu, jest GKrellM . Wyróżnia się on dużymi moż-

liwościami (potrafi monitorować kilkadziesiąt różnych wartości

i jest łatwo rozszerzalny poprzez wtyczki), a jego wygląd można

dostosować do własnych preferencji poprzez „skórki” ( skins ).

Użytkownicy Aurox Linux mogą znaleźć najnowszą wersję

wraz z dodatkami na freshrpms.net . Na tej stronie, po wybra-

niu „ Red Hat 9 ”, należy ściągnąć pakiet fftw oraz pakiety

gkrellm , gkrellm-plugins , gkrellm-themes .

Po uruchomieniu aplikacji i naciśnięciu klawisza [ F1 ],

możemy wybrać, które parametry systemu chcemy mieć na

bieżąco pod kontrolą. Wśród kilkudziesięciu z nich, najpopu-

larniejsze to oczywiście obciążenie procesora i sieci, zajętość

i praca dysków oraz oczywiście czujniki komputera. Aby oglą-

dać wyniki ich odczytów w GKrellM, musimy najpierw skonfi-

gurować Lm_sensors, w przeciwnym razie w dziale „Czujniki”

(„ Sensors” ) nie znajdziemy żadnych pozycji do zaznaczenia.

GkrellM można także używać do innych zadań, np. podgląd

kamery internetowej, sprawdzanie, czy dany komputer odpo-

wiada na pingi , informowanie o nowej poczcie, a nawet jako

mikser dźwięku, tuner radiowy i wielu innych.

Pośród wielu zalet tego programu trzeba wymienić pełną

konfigurowalność, bardzo dobrą pomoc (również spolszczoną),

którą można znaleźć w zakładce „ Info ” przy każdej pozycji

w konfiguracji, oraz możliwość ustawienia wielu zaawansowa-

nych parametrów, wyłącznie przy użyciu myszki.

smartctl -H /dev/hda

Ostatnia linia wyniku działania tej komendy powinna

wyglądać tak:

SMART overall-health self-assessment test result: PASSED

Jeśli zobaczymy tam FAILED zamiast PASSED, oznacza

to, że dysk już uległ poważnej awarii bądź najprawdopo-

dobniej ulegnie jej w ciągu 24 godzin. Nawet jednak, gdy

dysk twierdzi, iż jest sprawny, dobrze jest przeprowadzić

pewne testy. Przy pomocy polecenia smartctl -t long

/dev/hda możemy uruchomić, trwający około godziny, test

dysku. Krótszy test – trwa poniżej 10 minut – uruchamiamy

poleceniem smartctl -t short /dev/hda . Testy te możemy

uruchamiać w czasie normalnej pracy dysku, gdy są na nim

zamontowane partycje. Ich wynik możemy sprawdzić po

zakończeniu poleceniem smartctl -l selftest /dev/hda .

Wszystkie informacje o dysku możemy uzyskać wywo-

łując polecenie smartctl -a /dev/hda | less . Nie należy

jednak wpadać w panikę, gdy zobaczymy jakieś błędy.

Ważne jest zwrócenie uwagi na wartość Reallocated_Sector_

Ct , która określa, ile sektorów zostało przeniesionych przez

dysk z powodu błędów. Jeśli mamy wartość większą niż

zero, oznacza to poważne problemy z dyskiem. Dodatko-

wo komenda ta pokazuje wiele ciekawych informacji, np.

aktualną temperaturę dysku ( Temperature_Celsius ) czy ilość

godzin „przepracowanych” przez dysk.

aplikacje można znaleźć w wielu dystrybucjach Linuksa,

a konfiguruje się je bardzo łatwo, przy pomocy myszki.

Dzięki nim możemy zawsze mieć na pulpicie podgląd

naszych czujników.

Technologia SMART

Jeśli nasz dysk twardy wspiera SMART, możemy z niego

„wyciągnąć” wiele ciekawych informacji. W tym celu

Listing 3. Wynik działania programu sensors po modyfikacji

/etc/sensors.conf

W Sieci:

che:~ # sensors it87-*

it87-isa-0290

Adapter: ISA adapter

Algorithm: ISA algorithm

VCore 1: +1.72 V (min = +1.42 V, max = +1.56 V) ALARM

VCore 2: +2.52 V (min = +2.40 V, max = +2.60 V)

+3.3V: +3.21 V (min = +3.13 V, max = +3.45 V)

+5V: +4.75 V (min = +4.72 V, max = +5.24 V)

+12V: +13.44 V (min = +11.36 V, max = +12.60 V) ALARM

VBat: +2.03 V

fan1: 3199 RPM (min = 0 RPM, div = 2)

M/B Temp: +40°C (low = +20°C, high = +40°C)

CPU Temp: +38°C (low = +25°C, high = +45°C)

Temp3: +16°C (low = +25°C, high = +45°C)

• Strona domowa projektu Lm_sensors:

http://www.lm-sensors.nu/

• Strona domowa projektu Smartmontools:

http://smartmontools.sourceforge.net/

• Program Alarmwatch:

http://www.dakotacom.net/~donut/

• Strona domowa programu GKrellM:

http://web.wt.net/~billw/gkrellm/gkrellm.html

• Strona domowa programu wyspecjalizowanego do odczy-

tu temperatury z twardych dysków:

http://coredump.free.fr/linux/hddtemp.php

• Baza danych na temat czujników na poszczególnych

płytach głównych:

http://mbm.livewiredev.com/mobolist.html

styczeń 2004

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: