Názory k článku
Oprava někdy nefungujícího USB u Intelu byla pro Linux 6.4 triviální
-
Opravdu to porušuje specifikace? Prý pro resume nebyla zapnutá podpora Configuration Request Retry Status, která je prý pro PCI-e povinná - viz https://blog.linuxplumbersconf.org/2017/ocw/system/presentations/4732/original/crs.pdf . Byla zapnutá jen pro reset, kde zařízení dává další čas na dokončení resetu - viz ten bug report
=====
The device may extend this 1 second delay through Request Retry Status completions and we accommodate for that in Linux with 60 second cap, only in reset code path, not in resume code path.
=====U resume by mi to dávalo smysl taky.
2. 5. 2023, 08:54 editováno autorem komentáře
-
Podle PCIe specifikace se FLR (function level reset) i jiny resety maji vykonat do 100ms. Pokud zarizeni potrebuje vice casu nez 100ms, tak muze vracet CRS, ale jen do doby 1 sec.
The endpoint is allowed to respond with CRS for one second before the OS
determines that the endpoint is faulty.Cokoliv co trva nad 1sec je fujky fuj na urovni zbernice - a takove zarizeni by spise melo resit readyness na urovni registru a driveru (viz napr. CSTS.RDY z NVMe specifikace).
Ta druha cast ohledne CRS visibility se tyka PCIe radice (ne zarizeni). Kdyz se cte VID:PID a nepripravene zarizeni tohle cteni zdrzuje skrze CRS, tak je tato cteci instrukce fakticky blokovana az do delky 1sec, nez to pcie radic vzda a zjisti se, ze cteni dopadlo timeoutem (a spravny bios resp. OS takove zarizeni prohlasi za vadne). Aby slo delat neco tedy bokem, tak se povoli CRSvisibility a to VID:PID cteni skonci po obdrzeni CRS zdrzovacky nejakym magic kodem (0001:FFFF) - a akceptovatelny inicializacni cas do 1sec si ma pohlidat pak software.
Ze nekdo povoluje 60sec pro tyhle pripady je totalne mimo specifikace. Ja bych to netoleroval a takovemu zarizeni odebral PCIe compliance.
-
Díky za detaily. Takže pokud jsem to dobře pochopil - zařízení může požádat o CSR, což ale ten resume v kernelu neumožňoval. Tedy pokud by se pravidla pro reset braly i pro resume, pak by to bylo o kernelu, ne o zařízení.
Ad délka čekání - dle specifikace je tedy max. čekání na potvrzení 1s, kernel dobrovolně čeká až 60s. To ale neznamená, že toto konkrétní zařízení korektní 1s timeout v CSR nestíhalo. Třeba jej stíhat mohlo, ale kernel jeho žádost o CSR při resume ignoroval.
Ale možná jsem to pochopil blbě.
-
Zarizeni nezada o CSR, ale odpovida na "configuration read request" paket tim CSR paketem ze jeste neni pripraveno (v dobe mezi 100ms a 1s od resetu, mezi 0-100ms by se system ani nemel ptat a po 1s se uz ptat nemusi). Je to neco jako aktivni NACK prave proto, aby se nemuselo spolehat na timeouty dle jinych pravidel.
Hledal jsem tech 60s a jak to vlastne je - tak pri bootu je pri enumeraci pouzito 60*1000 jako timeout pro kazde jednotlive zarizeni (pci i pcie). Nevim z ceho tato hodnota pochazi.. je to bez komentare primo takhle:
drivers/pci/probe.c: if (!pci_bus_read_dev_vendor_id(bus, devfn, &l, 60*1000))
Novy patch implementuje ten 1s timeout imho spravne na vsech ostatnich mistech kde k resetu dochazi (soft reset a resume):
https://www.spinics.net/lists/stable/msg638754.htmlProblem tedy nebyl ten, ze by TBT cip byl pomalejsi nez standard dovoluje, jen to, ze na te resume vetvi se nejspis necekalo do 1sec, ale po 100ms se rozhodlo ze to nejede a vyhodilo se zarizeni (puvodni bug 216728). Ted tam pridali to cekani do 1s a jede to pak ok.
Podle me to mohl byt side effect toho, ze bylo zaple CSRvisibility - tj. radic to cteni rovnou vracel s tim specialnim magic kodem, namisto "hw implementace 1s timeoutu" s CSRvisibility off - to by problem pomalejsi inicializace maskoval a resil na hw urovni.
