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

[Ladislav J. Horak]

Super, za sebe velmi děkuji....

L

po 11. 5. 2020 v 18:24 odesílatel Dan Lukes <dan at obluda.cz> napsal:
>
> 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
> --
> FreeBSD mailing list (users-l at freebsd.cz)
> http://www.freebsd.cz/listserv/listinfo/users-l