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@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@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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
