Jak na senzory?

[Roman Horník]

Jestliže potřebujete vědět například teplotu CPU, někdy GPU, čipsetu, otáčky větráků, napětí zdroje, ať už jen ze zvědavosti, z identifikace či prevence poruch (nežádoucí hodnoty napětí díky odcházejícímu zdroji, přehřívání způsobené vadným či zaneseným větrákem, nebo chladičem, průduchy apod.), nebo proto, že chcete mít svůj hardware plně pod kontrolou, jistě se vám bude hodit tento jednoduchý návod, který je vhodný i pro začínající, kteří se nebojí příkazové řádky (opravdu není čeho se bát).

Výstupy z oněch senzorů pak dokáže využívat nejen sensors, umí je využít i některé aplety mnoha desktopových prostředí, stejně tak si s nimi rozumí například i Conky. A není problém si takovou aplikaci potom napsat (třeba i s grafem), když už nám lm-sensors hodnoty strčí až pod nos.
Bohužel, zatímco na plnohodnotných počítačích, tedy těch stolních, obvykle nalezneme senzorů fůru, na laptopech, tabletech a podobných zmenšeninách jich bývá pomálu, není vzácností, aby tam nebyly žádné.
Ale nebudeme špekulovat, jdeme si to zkusit:

## Je-li potřeba, přihlásíme se v terminálu/konzoli jako kořen (root)
su -

## Nainstalujeme lm-sensors
aptitude install lm-sensors

## Vyhledáme senzory pomocí lm-sensors, automaticky odsouhlasíme všechny otázky, které nám položí
## (podívat se po tomhle? Podívat se po tamtom? Je to bezpečné, ušetří se tím klábosnice i čas)
yes | sensors-detect

## Zavedeme nalezené moduly, jsou vypsány v /etc/modules
service kmod start
## NEBO, pokud nám onen příkaz nefunguje
/etc/init.d/module-init-tools start

## Koukneme, co nám senzory říkají (není potřeba spouštět jako superuživatel)
sensors

Mně z toho vyleze:

Kód: [Vybrat]

root@DebianSid:~# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +44.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:       +40.0°C  (high = +86.0°C, crit = +100.0°C)

w83627ehf-isa-0290
Adapter: ISA adapter
Vcore:        +1.26 V  (min =  +0.00 V, max =  +1.74 V)
in1:          +1.62 V  (min =  +1.94 V, max =  +0.46 V)  ALARM
AVCC:         +3.33 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:        +3.38 V  (min =  +2.98 V, max =  +3.63 V)
in4:          +1.90 V  (min =  +1.53 V, max =  +2.01 V)
in5:          +0.02 V  (min =  +1.02 V, max =  +2.04 V)  ALARM
in6:          +0.02 V  (min =  +1.40 V, max =  +1.66 V)  ALARM
3VSB:         +3.34 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:         +3.26 V  (min =  +2.70 V, max =  +3.63 V)
in9:          +0.02 V  (min =  +0.89 V, max =  +1.75 V)  ALARM
fan1:        2445 RPM  (min =  666 RPM, div = 8)
fan2:         964 RPM  (min = 1328 RPM, div = 8)  ALARM
fan3:           0 RPM  (min =    0 RPM, div = 128)
fan5:           0 RPM  (min = 84375 RPM, div = 16)
temp1:        +43.0°C  (high = -123.0°C, hyst = -67.0°C)  ALARM  sensor = thermistor
temp2:        +21.5°C  (high = -112.0°C, hyst = -112.0°C)  ALARM  sensor = CPU diode
temp3:        +38.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
cpu0_vid:    +1.219 V
intrusion0:  ALARM
Kde je ALARM, tam jsou většinou prohozené či nesmyslné limity, což je chyba v lm-sensors. Naměřené hodnoty jsou ale správně, akorát u napětí vyšších jak 5V je nepřesnost o něco vyšší, neboť se tyto hodnoty často měří na odporovém děliči s jistou tolerancí hodnot (max. vstupní napětí čipu senzorů bývá jen 5V).
Coretemp je senzor uvnitř CPU, měří teplotu, Winbond W83627EHF je brouk, co sleduje to ostatní.
Jinak ten intrusion0 je spínací kontakt, který je u uzavřené skříně sepnutý (stisknutý), jakmile se skříň otevře, spínač rozepne, jako porucha (neoprávněné otevření) se zapíše (i ve vypnutém stavu) do paměti BIOSu, který to po spuštění stroje napráská. Většinou nepotřebná věc, ale v senzorech vidět je.

[Palo M.]

lm-sensors pouzivam uz dlhe roky, tak si dovolim mierne doplnit:

Konfiguracia k senzorom je v subore /etc/sensors3.conf
Je tam specifikovane, ktory vstup meracieho cipu je pripojeny na ktory senzor, ake su pripadne prepocty medzi hodnotami a napatim (niektore vstupy musia byt zapojene cez napatovy delic z dvoch rezistorov, pretoze meracie cipy pracuju len v urcitom rozsahu, takze napriklad meranie +12V zo zdroja musi byt zredukovane do rozsahu 0 az 3.3V). Meracich cipov je vela a vacsina z nich ma nejake odporucane zapojenie a na zaklade tej dokumentacie bol napisany ten subor sensors3.conf

Podla mojich skusenosti s viacerymi doskami za tie roky (rozne modely MSI, Gigabyte, ASUS) mi ten standardny obsah suboru nikdy dobre nefungoval a vzdy bolo niekolko sensorov (casto vacsina zo senzorov) uplne nezmyselnych (napriklad boli nepomenovane teda sa zobrazovali ako "in8", alebo boli uzemnene takze stale ukazovali nulu, pripadne boli pravdepodobne nezapojene a ukazovali nezmyselne nahodne hodnoty, alebo skratka nesedel prepocet lebo vyrobca dosky ich zapojil inak nez bola odporucana schema). Tieto neduhy nesediaceho konfiguraku su vidiet aj na Romanovom vypise
To sa da vzdy napravit dodanim vhodneho konfiguraku. Niekedy ma clovek stastie a najde konfiguraciu tu: http://www.lm-sensors.org/wiki/Configurations, ale najlepsie je googlit podla presneho modelu svojej dosky a najdeneho mena senzoroveho cipu, vacsinou to najde niekoho, kto uz konfigurak pre danu dosku vytvoril, staci ulozit novy subor (len s tymi nastaveniami pre moju dosku) do adresara /etc/sensors.d/ (a suboru /etc/sensors3.conf sa netreba chytat), restartovat sensors a potom skontrolovat, ake hodnoty to zobrazuje. Ak by to nesedelo, alebo bol k dispozicii len konfigurak k podobnej doske, tak potom treba upravovat a kontrolovat (podla informacii co pise o teplotach a otackach BIOS), castokrat su to len prehodene vstupy... Prinajhorsom sa daju aspon dat do ignore tie vstupy, ktore su nepomenovane alebo ich hodnoty nedavaju zmysel (mozno su tie vstupy aj zapojene, ale nevieme ake rezistory su pouzite)...
Samozrejme, niekedy este treba upravit veci podla svojej situacie, napriklad ventilatory - nezapojene do ignore nech ich ani nezobrazuje. A zapojenym zase nastavit minimalne otacky (pri klesnuti otacok sa objavi ten ALARM) a aj ich pomenovat ("CPU Fan" a "Front Fan" vyzeraju lepsie nez fan1 a fan4), niekedy treba manualne upravit hodnotu div (kolko pulzov za otacku ventilator posiela - to je dane konstrukciou konkretneho ventilatora).
A celkovo... man sensors.conf je nas kamarat

Co sa tyka notebookov, tie nemaju specialne senzorove cipy na doske, ale vacsinou sa da teplota puzdra procesora a teplota dosky ziskat z ACPI informacii (treba mat nainstalovane nejake baliky k ACPI, presne si to teraz nepamatam, lebo notebook nepouzivam). No a samozrejme, modul coretemp by mal fungovat pre vsetky Intel procesory (pre AMD je zase k8temp alebo k10temp), tym sa da zistit zase teplota jadier procesora... takze nejake informacie o teplotach sa daju ziskat aj na notebookoch.

So senzormi suvisi este to, ze pouzivam aj munin na monitorovanie, kedy sa tie hodnoty nacitanych senzorov vykresluju do grafu. Aj ked munin je univerzalny, teda nie len na senzory (sledujem tym aj S.M.A.R.T. diskov, load v systeme, siet, atd)... ale pri tych senzoroch je vidiet, ako sa menia teploty v zime a v lete (pripadne ked sa filltre zas upchaju prachom a ked ich potom vycistim ). Pre mna ma munin vyznam hlavne preto, ze takto mozem monitorovat vsetky svoje stroje, server ktory zbiera udaje mi bezi stale. Ak ma niekto len jeden desktopovy stroj (alebo notebook), tak sa munin velmi nehodi... ale uz som videl nejake screenshoty ako mali ludia udaje zo senzorov na desktope cez conky. No a desktopove prostredia asi maju nejake pekne widgety pre tych, co to chcu mat na ociach "live" (sam tiez nepouzivam, ale mozno niekto iny da tip pre ostatnych).

[Roman Horník]

No vidíš to, a jako na potvoru limity hodnot pro křičící senzory v sensors3.conf nemám:

Kód: [Vybrat]

chip "w83627ehf-*" "w83627dhg-*" "w83667hg-*" "nct6775-*" "nct6776-*"

    label in0 "Vcore"
    label in2 "AVCC"
    label in3 "+3.3V"
    label in7 "3VSB"
    label in8 "Vbat"

    set in2_min  3.3 * 0.90
    set in2_max  3.3 * 1.10
    set in3_min  3.3 * 0.90
    set in3_max  3.3 * 1.10
    set in7_min  3.3 * 0.90
    set in7_max  3.3 * 1.10
    set in8_min  3.0 * 0.90
    set in8_max  3.3 * 1.10Ale dlabu na to, mně zajímají aktuální hodnoty, ne povolený minima/maxima, který si stejně pamatuju 

P. S.: Ani jeden jsme se netrefili:
Most voltage sensors in sensor chips have a range of 0 to 4.08 V. This is generally sufficient for the +3.3V and CPU supply voltages, so the sensor chip reading is the actual voltage.

[Palo M.]

Defaultne hodnoty su myslim nastavene v driveri kazdeho cipu - ten driver je ale sucastou kernelu, takze driver a sensors3.conf nemusia byt uplne konzistentne.

Zas az tak vela roboty s tym nie je; Ked si tuto sekciu skopirujes do samostatneho suboru do toho sensors.d a pridas tam nieco taketo:

Kód: [Vybrat]

ignore in1
ignore in4
ignore in5
ignore in6
ignore in9
set fan2_min 800
ignore fan3
ignore fan5Tak ti z vypisu zmiznu tie smeti (a aj alarm pre fan 2 - teda ak je to pomalobezny ventilator a naschval ide pomaly - v opacnom pripade radsej vymen ventilator )

Do 3.3V sa vacsinou pripaja na senzory priamo, ale to som viac-menej pisal... je tam do tych 4.08 rezerva. Ale zo zdroja ide aj +5V a +12V a tie by sa uz do toho nezmestili, preto potom nastupuje napatovy delic. A tie +5V a +12V hodnoty su pre monitoring stavu zdroja dost uzitocne, lebo napajaju dolezite periferie (grafiku, disky)

[Roman Horník]

Vím, kde v jádru ten ovladač je, ale nebudu se v něm šťourat, protože ani nevím přesně, na co kterej senzor je. Že jo, mám tam 1.6V, 1.9V, nevím, co jsou temp2 a temp3. W83627EHF je sice furt ten stejnej, jenom to jeho zapojení na desce je tak trochu unikátní.
sensors3.conf jsem náhodou upravoval už včera, takhle to vypadá:

Kód: [Vybrat]

sensors
V-core:       +1.37 V  (min =  +0.00 V, max =  +1.74 V)
1.6V:         +1.62 V  (min =  +1.44 V, max =  +1.76 V)
AVcc:         +3.34 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:        +3.34 V  (min =  +2.98 V, max =  +3.63 V)
V-RAM:        +1.89 V  (min =  +1.62 V, max =  +1.98 V)
in5:          +0.02 V  (min =  +0.01 V, max =  +0.20 V)
in6:          +0.02 V  (min =  +0.01 V, max =  +0.20 V)
3V-SB:        +3.34 V  (min =  +2.98 V, max =  +3.63 V)
V-bat:        +3.23 V  (min =  +2.70 V, max =  +3.63 V)
in9:          +0.02 V  (min =  +0.01 V, max =  +0.20 V)
GPU-vent:    2163 RPM  (min =  688 RPM, div = 8)
CPU-vent:     948 RPM  (min =    0 RPM, div = 16)
fan3:           0 RPM  (min =    0 RPM, div = 128)
fan5:           0 RPM  (min =    0 RPM, div = 128)
temp1:        +43.0°C  (high = +80.0°C, hyst = +70.0°C)  sensor = thermistor
temp2:        +21.5°C  (high = +80.0°C, hyst = +70.0°C)  sensor = CPU diode
temp3:        +39.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
cpu0_vid:    +1.219 V
Ten větrák je v pořádku, je to větrák chladiče CPU, nějakej Arctic Cooler Freezer Pro rev. 2.0, vyleze max na 1000 ot./min., ale během kompilace teplota jader (pouzdro je chladnější) nepřesáhne 62°C.

[Palo M.]

Tusim som to v mojej odpovedi prilis zhustil a kvalitne som ta zmiatol... tak sorry.

1. Ovladac je dovod, preco ti to vypise nejake veci navyse (vacsinou neuzitocne somariny), aj v tom pripade ak v /etc/sensors3.conf dane somariny nie su nakonfigurovane. To bolo len na vysvetlenie. V ovladaci sa rozhodne nebudeme vrtat, nemame preco .

2. V subore /etc/sensors3.conf su nejake defaultne nastavenia. Je to sucastou balika (libsensors4, lm-sensors od neho zavisi) a ja odporucam tento subor takisto nemodifikovat. Ak ho zmodifikujes, tak sa nic tragicke nestane, akurat pri update balika sa ti moze stat, ze v baliku je novsia verzia a teda zacne balickovy system nadavat, ze si subor modifikoval, ci ma nechat tvoju verziu alebo dat balickovu alebo chces vidiet rozdiely... take updaty nebyvaju casto, vo vetve stable sa s tym asi vobec nestretnes, ale ak mas vetvu testing alebo unstable, tak sa s tym pravdepodobne stretnes.

3. Ak pridas do adresara /etc/sensors.d svoj subor, tak tento sa pouzije uplne rovnako ako /etc/sensors3.conf (rovnaky format), akurat ze uz nebude sucastou balicka a teda sa ho balickovaci system nebude chytat a nebude pindat pri updatoch. Prave preto odporucam davat vlastne nastavenia prave sem. Z hladiska behu lm-sensors je to rovnake, ale z hladiska balickoveho systemu je to cistejsie. Navyse, tvoj subor nebude taky siahodlhy ako cely /etc/sensors3.conf, ale tam bude len jedna sekcia s tvojim chipom, teda sa ti lahsie cita aj edituje. Ale toto je uz len taky perfekcionizmus. Ked uz si to zmodifikoval v /etc/sensors3.conf a bezi to, tak je najjednoduchsie nechat to uz tam.

Vyrobcovia dosiek tie senzorove cipy zapajaju inak (nez je odporucane v dokumentacii k cipu) pravepodobne preto, ze im to lepsie vyhovuje z hladiska rozlozenia suciastok na doske a navrhu plosnych spojov. Potial moze byt. Len ma stve, ze sa nikdy neda najst dokumentacia k danej doske, ako to pri nej zapojili (pritom je to uplne nepodstatny detail ktory nemaju dovod utajovat, len to skratka odflaknu a nezverejnia to - takze vo vysledku senzory su na doske a meraju, ja mam program co ich vie citat, ale neviem ako tie hodnoty interpretovat a stve ma to... trochu). Obcas sa nieco da zistit empiricky, ale pravdu povediac po tolkych rokoch (a doskach) uz ma nebavi experimentovat s roznymi prepoctami a hladat, ktory senzor moze byt na 5V a ktory na 12V...

Tie "neidentifikovane" teploty si skus porovnat s tym, co ti pise BIOS. Vacsina BIOSov udava aspon 2 teploty: CPU-temperature byva teplota puzdra CPU (a byva nizsia nez coretemp ktore su teploty vo vnutri jadier reportovane priamo procesorom). A potom byva System-temperature (alebo NB-temperature), ktora je vacsinou niekde pri chipsete (alebo je to senzor priamo z chipsetu), obvykle byva nizsia nez teplota CPU. No a casto byva v senzoroch este jedna teplota, ktora v BIOSe nie je zobrazovana, ale v lm-sensors ju vidis a zjavne je to nejaka ozajstna teplota (je v realnych medziach a kolise). Vyzera to na teplotu napajacich obvodov a na niektorych doskach byva aj vyssia nez teplota CPU, ale niekde zase nizsia, niekedy byva pomerne stabilna pri meniacej sa zatazi CPU a niekde kolise podobne ako CPU... Niekde som ju videl zobrazenu ako AUX-temperature (myslim ze to boli nejake Windozacke tooly - to bolo este davno pradavno) tak pouzivam toto meno, aj si nie som isty, aka teplota to je .
Ked nakuknes do BIOSu, mozno sa ti tie teploty podari sparovat, alebo aspon niektore z nich.

[Palo M.]

Tak predsa len ešte jeden dodatok, niekomu by to mohlo pomôcť. Tentokrát to bude trocha drsnejšie

Keď som pomerne nedávno menil dosku, tak ma pri sensors-detect privítala takáto hláška (úryvok z dlhého výpisu):

Kód: [Vybrat]

...
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found unknown chip with ID 0xc562
    (logical device B has address 0x290, could be sensors)
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
...Takže sensors-detect našiel, že je prítomný "nejaký" čip. Ale potom žiadne senzory z dosky neboli zobrazené.
Pre informáciu, ide o tento čip, Nuvoton NCT6779D:


Ta nepríjemná hláška je dôsledkom toho, že lm-sensors nemá ovládač k danému čipu a nevie s ním preto pracovať. S novým hardvérom sa také veci stávajú. Povedal som si, že označenie senzorového čipu je už rozumná východzia informácia a okrem toho existuje fenomén "dobrých duší na internete" (to sú takí tí ľudia, čo niečo spojazdnia hlavne pre seba, a potom sa o to podelia s ostatnými tým, že to zverejnia na nete). Po krátkom hľadaní som sa dostal k nasledujúcej stránke: https://github.com/groeck/nct6775 Hurá! Dobrá duša napísala ovládač. Moje šance sa prudko zvýšili. Po krátkom overení, že v mojom jadre sa ten ovládač naozaj nenachádza, mi bolo jasné, že ho tam treba len nejako dostať.

Možností je (ako obvykle) viac, napríklad novšie jadro ktoré už ovládač obsahuje, ja som však chcel zostať pri distribučnom jadre. Aby som sa nemusel ďalej starať o celé jadro, iba o tento jeden ovládač, ak by bolo treba (a to pravdepodobne potrebné nebude). Skompilovať si celé vlastné jadro je síce fasa, ale potom ho priebežne updatovať je otrava.
Na pridávanie ďalších jednotlivých ovládačov do jadra našťastie máme DKMS (Dynamic Kernel Module Support), ktorý zabezpečí presne to, čo potrebujem (DKMS sa používa napríklad pre VirtualBox alebo pre proprietárne ovládače na grafické karty AMD/ATI). Jadro si žije samostatným životom a ak sa v dôsledku update nainštaluje novšia verzia jadra, tak DKMS zabezpečí, že náš modul sa hneď po update automaticky skompiluje aj pre nové jadro.

Tak ideme na to:

Ak náhodou ešte nemáme nainštalované DKMS, tak ho najskôr nainštalujeme:

Kód: [Vybrat]

apt-get install dkms
1. Najprv si stiahneme zdrojový kód ovládača. Väčšinou priame linky smerujú na poslednú verziu z repozitára. Aj v tomto prípade stránka https://github.com/groeck/nct6775 ponúka na stiahnutie archív s aktuálnou verziou, konkrétne https://github.com/groeck/nct6775/archive/master.zip. Ja mám však rád poriadok. O pár dní môže prísť nová verzia a archív bude iný. Ja chcem mať záznam o tom, ktorú verziu používam. Takže sťahujem konkrétnu verziu, commit do git-u s označením 33a206276b z 8. marca (mimochodom, momentálne už existuje aj novší commit, ale pri jeho kompilácii sa objavuju varovania, takže som sa rozhodol pre mierne staršiu verziu):

Kód: [Vybrat]

wget -O nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd.zip https://github.com/groeck/nct6775/archive/33a206276bf692be5081423ce5e7b4cc6bf0d7fd.zip
2. Pre istotu si skúsime naprázdno kompiláciu zdrojového kódu samostatne (ešte nie sme v DKMS):

Kód: [Vybrat]

7z x nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd.zip
cd nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd/
makeKompilácia mi prebehla dobre, modul samostatne je kompilovateľný, v adresári máme súbor nct6775.ko, to je skompilovaný modul jadra (pre konkrétnu verziu jadra, ktoré nám práve beží). Super. Upraceme po sebe:

Kód: [Vybrat]

make clean
ls -al
cd ..
rm -rf nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd/(pomocou make clean a následného ls si overíme, že autor kódu to neodflákol a nenecháva po sebe smeti)

3. Pripravíme modul pre DKMS:
Stanovíme verziu. Keďže je to modul len pre našu osobnú potrebu, môžeme byť kreatívny. Ja som zvolil verziu  0.9~0git+33a206276b. Vyzerá to trocha zložito, takže pripájam aj vysvetlenie: V git repozitári je vidieť, že pred časom autor "otagoval" istú verziu ako 0.9. My však máme novšiu verziu z git-u, označenie commitu je 33a206276b, preto to zahŕňam do čísla verzie, aby hocikedy neskôr bolo jasné, aká verzia zdrojového kódu bola použitá. V číslach verzií balíkov sa neodporúča používať znak pomlčky, miesto toho sa dáva +. 0git preto, že je to úplne prvý pokus o tvorbu tohoto DKMS-modulu. A znak ~ spôsobí, že moje číslo verzie bude "menšie" než verzia 0.9 (dá sa overiť cez dpkg --compare-versions "0.9~0git+33a206276b" lt "0.9" ; echo $?), takže ak by náhodou vyšla oficiálna verzia tohoto modulu s číslom verzie 0.9, bude považovaná za novšiu. Dekryptované toto číslo verzie teda znamená: verzia 0.9, privátny build číslo 0, zdroj z git=u, commit 33a206276b.
No super, máme čislo verzie... to sa používa aj v názve adresára, ktorý má formát <menomodulu>-<verzia>

Kód: [Vybrat]

7z x nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd.zip
mv nct6775-33a206276bf692be5081423ce5e7b4cc6bf0d7fd nct6775-0.9~0git+33a206276b
A vytvoríme súbor nct6775-0.9~0git+33a206276b/dkms.conf s nasledovným minimalistickým obsahom:

Kód: [Vybrat]

PACKAGE_NAME="nct6775"
PACKAGE_VERSION=0.9~0git+33a206276b
BUILT_MODULE_NAME[0]="nct6775"
DEST_MODULE_LOCATION[0]="/kernel/drivers/hwmon"
AUTOINSTALL="yes"
(Doteraz sme fungovali pod bežným užívateľom, teraz ale ideme robiť systémové veci, takže pred ďalšími krokmi použijeme su alebo sudo.)

4. Zahrnieme modul do DKMS systému:

Kód: [Vybrat]

cp -r --preserve=time nct6775-0.9~0git+33a206276b/ /usr/src/
dkms add nct6775/0.9~0git+33a206276b
5. Povieme DKMS aby si skompiloval modul v ramci svojho systemu:

Kód: [Vybrat]

dkms build nct6775/0.9~0git+33a206276b
6. Pridáme DKMS modul do adresára modulov nášho jadra:

Kód: [Vybrat]

dkms install nct6775/0.9~0git+33a206276b
7. Moment pravdy, pokúsime sa načítať náš nový modul do bežiaceho jadra:

Kód: [Vybrat]

modprobe nct6775
lsmod | grep nct6775
8. Ak sme sa dostali až sem a nevyhodilo nám žiadne chyby, náš nový modul je zavedený v jadre a môžeme ho používať:

Kód: [Vybrat]

sensors -s
sensorsA máme funkčné senzory!
Ak všetko funguje, pridáme do /etc/modules riadok:

Kód: [Vybrat]

nct6775aby sa nám modul vždy automaticky nahral pri štarte systému.
No a samozrejme vytvoríme konfiguračný súbor v /etc/sensors.d/ špecifický pre daný čip. V mojom prípade začína s:

Kód: [Vybrat]

chip "nct6779-*"
(Modul jadra sa volá nct6775, ale pokrýva niekoľlo čipov a ten môj je lm-sensors rozpoznaný ako nct6779-isa-0290)

V prípade, že chceme tento modul odstrániť (máme novšiu verziu modulu, meníme dosku, apod):

Kód: [Vybrat]

dkms uninstall nct6775/0.9~0git+33a206276b
dkms remove nct6775/0.9~0git+33a206276b -all
rm -rf /usr/src/nct6775-0.9~0git+33a206276b/Týmto úplne odstránime náš DKMS modul zo systému, necháme za sebou pekne poupratované, čistá prácička.

DKMS je samozrejme použiteľné pre akékoľvek moduly jadra. Grafika, zvukovka, TV-karta,... Mne sa akurát nedávno stalo, že práve pre senzory som to potreboval. A tento konkrétny čip ešte stále nie je podporovaný ani tým jadrom, ktoré je momentálne vo Wheezym. Takže ak má niekto dosku Asus P8Z77-M PRO, môže tento návod rovno použiť... a je možné, že aj iné dosky od Asusu používajú senzorové čipy tejto rady.

[Ota Trkola]

Zajímavé. Musím na to DKMS mrknout. Na desktopu jsem místo radeon driveru začal používat fglrx-legacy, takže by se to mohlo hodit.