System mi nenachazi zarizeni (lehky uvod do troubleshootingu detekce zarizeni).

[Dan Lukes]

Pred chvili jsem v jinem emailu lehce nactrtnul jak vypada PCI sbernice 
v pocitaci a jak na ni FreeBSD nachazi zarizeni a a hleda pro ne ovladace.

Ted se chci povenovat situaci kdy se nejake zarizeni nenajde a my 
hledame co je spatne (nasledne proc a nasledne jak to opravit).

Jednodussi varianta je, kdyz nam system nabehne do alespon tak funkcniho 
stavu, ze mame prikazovou radku, dokazeme spustit pciconf -lvb, ve 
vzniklem vypisu vidime zairzeni, ktere hledame, ale jmeno zarizeni 
vypada jako "noneX" kde X je nejake cislo.

Treba takhle:
> none2 at pci0:0:31:3:      class=0x0c0500 card=0x1c228086 chip=0x1c228086 rev=0x05 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '6 Series/C200 Series Chipset Family SMBus Controller'
>     class      = serial bus
>     subclass   = SMBus
>     bar   [10] = type Memory, range 64, base 0xf7c01000, size 256, enabled
>     bar   [20] = type I/O Port, range 32, base 0x580, size 32, enabled

To znamena, ze system zarizeni nasel, uspesne mu priradil pozadovane 
adresni bloku - jen pak pro nej nenasel ovladac.

V lepsim pripade dokonce vite jaky vladac by zarizeni mel ovladat - pak 
je prakticky jiste, ze tento ovladac v systemu proste nemate. 
Nedopatrenim vam vypadl z konfigurace kernelu (pokud si prekladate 
vlatni), nenahravate ho dynamicky v loader.conf, po vypadku napajeni a 
poskozeni disku vam soubor s ovladacem fsck smazlo, po upgrade zustal v 
systemu modul ovladace z predchoziho systemu, chybi nejaky uplne jiny 
modul na nemz je ale tento ovladac zavisly ...

Resenim je zkonstrolovat, ze ovladac je kde ma byt (v kernelu, v 
loader,conf a pod) a podivat se na zaznam bootu systemu - pokud ovladac 
nebyl nalezen, nepatri verzi k danemu systemu nebo nema pozadovane 
zavislosti k dispozici, melo by to tam byt napsane.

Reseni je v tomhle pripade asi zrejme.

Horsi je, kdyz nevime jaky ovladac presne by mel zarizeni obsluhovat.

Zde je klicovou informaci vendor_id/device_id (uvedene v obracenem 
poradi na radku chip="). Jednak se muzete zaeptat Googlu na
"FreeBSD chip=0x1c228086"
pri trose stesti najdete nekoho kdo resil stejny problem a pri trose 
stesti tam najdete i radu jaky ovladac pouzit. Nekdy je uspesnejsi dtaz, 
kde se odentifikace rozdeli, tedy
"FreeBSD 8086 1c22"

Hrdy bojovnik to ale nejdriv zkusi zvladnout sam, tak, ze zkusi ve 
zdrojacich ovladacu najit identifikaci zarizeni:

> grep -iR 1c22 /usr/src/sys/dev

Dostane:

> /usr/src/sys/dev/ichsmb/ichsmb_pci.c:#define    ID_CPT                          0x1c22
> /usr/src/sys/dev/ispfw/asm_2500.h:      0x31d20370, 0x2231c222, 0xe0260790, 0xf5e0a3fa,
> /usr/src/sys/dev/bce/if_bcefw.h:0x196c00, 0x187400, 0x25e2ffee, 0x1c22025,
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x0000f300, 0x0dc00000, 0x0000e180, 0xc8a10420, 0x00004901, 0x00001c22, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x000083f8, 0x0f400000, 0x0000e180, 0xc721103f, 0x00006003, 0x00001c22, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00006180, 0xc8a1cc39, 0x00004901, 0x00001c22, 0x00009583, 0x10400000, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00001900, 0x83800e38, 0x00009283, 0x81408000, 0x00006189, 0x0801c220, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00006110, 0x88b19e33, 0x00006111, 0x0801c222, 0x0000e110, 0x00000001, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00004901, 0x00001c22, 0x00009583, 0x0e400000, 0x00009988, 0x04110039, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00008080, 0x0801c220, 0x00006900, 0x80001a20, 0x00001582, 0x88001220, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x000021b6, 0x01802000, 0x00007930, 0x00211c22, 0x00000980, 0x000053eb, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x8c11c22f, 0x00009100, 0x8bc07a30, 0x0000e780, 0x0bc1ac30, 0x0000a000, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x0303c000, 0x00009999, 0x00002ad7, 0x0000f019, 0x00031c22, 0x00009583, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x6161c22c, 0x0000a101, 0x6151422c, 0x00002102, 0xffffffff, 0x00007f97, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x6161c22a, 0x0000a101, 0x50864e0a, 0x00007300, 0x0a100800, 0x00001980, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x0000e000, 0x0c01c221, 0x00002100, 0x00002097, 0x00007430, 0xea39a61e, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x0000d000, 0x00390800, 0x00008000, 0x07400a38, 0x0000e198, 0x0c01c221, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00006283, 0x0c01c223, 0x0000a100, 0x81840000, 0x0000e188, 0x81800000, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x0000e000, 0xc1401739, 0x00006283, 0x0c01c223, 0x0000a100, 0x81840000, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00000980, 0x01001c22, 0x00009283, 0xffffffff, 0x00007f86, 0x00006a5b, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x00005684, 0x00000002, 0x00008480, 0xaf801c22, 0x0000f88f, 0x03000001, 
> /usr/src/sys/dev/qlnx/qlnxe/ecore_init_values.h:        0x000081ec, 0x07000000, 0x000081f4, 0x07800000, 0x000081fc, 0x01001c22, 
> /usr/src/sys/dev/qlnx/qlnxe/reg_addr.h:#define CAU_REG_IGU_CMD_FIFO 

To znamena, ze moznymi kandidaty jsou ichsmb, ispfw, bce, qlnx. Vzhledme 
k tomu, ze zarizeni se jmenuje "SMBus Controller" tak ja bych okamzite 
sel po ichsmb, ale resenim je o proste nahrat (pokud uz v systemu 
nejspou) vsechny. Samozrejem postupne. Pozor, u nekterych zarizeni sice 
existuje loadable modul, ale kdyz ho nahrajete az za behu, uz zarizeni 
nenajde. Takze pokdu selzou vsechny pokusy s kldload, napiste napravani 
modulu do loader.conf tak, aby se nahraly jeste pred startem systemu.

Ja ale davam "kldload ichsmb", na konzoli se objeci:

> ichsmb0: <Intel Cougar Point SMBus controller> port 0x580-0x59f mem 0xf7c01000-0xf7c010ff irq 18 at device 31.3 on pci0
> smbus0: <System Management Bus> on ichsmb0

a uspech potvrzuje i pciconf -vlb:

> ichsmb0 at pci0:0:31:3:    class=0x0c0500 card=0x1c228086 chip=0x1c228086 rev=0x05 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '6 Series/C200 Series Chipset Family SMBus Controller'
>     class      = serial bus
>     subclass   = SMBus
>     bar   [10] = type Memory, range 64, base 0xf7c01000, size 256, enabled
>     bar   [20] = type I/O Port, range 32, base 0x580, size 32, enabled

Ke skemrani u Googlu se uchylim teprve pokud to takhle jednoduse vyresit 
nejde.

Dosud byla rec o situaci, kdy spravny ovladac pro FreeBSD existuje, jen 
ho z nejakeho duvodu nemame korektne pritomny. Potiz ale muze byt v tom, 
ze jsme si koupili nejaky hodne novy stroj a v nem je nejaka nova 
varianta chipu, kterou stavajici ovladace neznaji.

Zde uz se dostavame do oblasti "odhadu, pokusu a vlivu stesti". Rada 
ovladacu poznava "sva" zarizeni vyhradne podle kombinace 
vendor_id/device_id. Nezridka je cely problem v tom, ze v_id/d_id naseho 
zarizeni "proste jen neni v seznamu" a proto se k nemu existujici 
ovladac nezna.

Staci tedy do zdrojoveho kodu ovladace identifikaci doplnit a muze byt 
vyreseno. nebo taky ne, pokud novy chip neni puvodnim podobny dost a 
ovladac s nim ve skutecnosti pracovat nebude umet (prestoze ho donutime 
si myslet, ze ano). Aniz bych vas chtel strasit, tenhle "postup na tupo" 
ma i hypoteticka rizika - v krajnim pripade muze dojit i ke zniceni 
hardware. realne riziko je velmi male, ja sam tenhle typ uprav delam bez 
velkeho rozmysleni, ale pokud se neco stane, nerikejte, ze jsem vas 
nevaroval.

Nechci se venovat tomu jak najdete misto kam v kodu ovladace tu 
identifikaci napsat. Pokud jen trosicku programujte nebo mate nadani, 
pak vhodne misto vetsinou zretelne uvidite. Pokud jste nikdy cizi 
programy necetli, pak je to samostatne tema a to sem ted nechci tahat.

Specialnim a spise raritnim pripadem problemu je, kdy se vam na zarizeni 
chyti ovladac, ale ne ten, ktery by mel. Hardwarova zarizeni totiz ani 
nahodou nejsou chyb prosta. Neni az ta vzacne, ze zarizeni, ktere o sobe 
deklaruje podporu nejakeho API toto API neimplementuje korektne a 
ovladac musi rozpoznat, ze na "tohle zvire je treba mluvit trochu 
jinak". Vyskytuji se pripady, kdy zarizeni, ktere neni bridge 
prohlasije, ze jim je (a kvuli tomu mu system priradi ovladac pro 
bridge, ktery ale samozrejme nefunguje) - ale taky situace obracene, 
bridge v konfiguraci preda, ze bridge neni (a pokud na to system 
neprijde, tak mine vsechny sbernice, ktere za timto bridgem jsou).

Vetsina pripadu tohoto typu vznika u velmi noveho hardware (pripadne u 
nejakeho raritne se vyskytujiciho) a resenim je vlastni uprava 
zdrojoveho kodu (aby se k zarizeni nehlasil ovladac, ktery nema a/nebo 
hlasil ten, ktery ma). U bezneho a starsiho hardware se to nedeje proto, 
ze na problem uz nekdo prisel a potrebne "vyjimky" uz v kodu systemu jsou.

V pristim (poslednim) emailu se budu venovat variante, ze pocitac 
konkrenti koncove zarizeni (nebo celou sbernici) vubec nevidi.

Dan