Oprava chyby v intel_idle na BayTrail SoC (diskuse)

[cezz]

Co si spominam, tak tych patchov co to opravili bolo uz niekolko, tak snad je tento naozaj funkcny. (nic v zlom, developeri viac-menej tipuju kde by mohol byt problem, skutocna pricina je zrejme proste vadny HW a tie patche su len workaround)

[frr]

Jojo... v kontextu aktuální aféry C2000 series (úplně jiný problém) a ve světle nějakých historických insider mailů co mám od malých TW výrobců... se samozřejmě škrábu na hlavě, jestli je (opět) chyba v křemíku, nebo se k němu linux třeba jenom choval nedostatečně uctivě. Nebo jinak než Windows, chtělo by se říci, ale našel jsem i zmínky, že někomu mrznou i Windows... což se v mém případě nepotvrdilo.

To dlouhé vlákno bug reportu končí pár pochvalnými referencemi, že uvedený patch funguje a že ho autor předložil maintainerům. Tak snad konečně. Koukal jsem, co je ten patch zač... víceméně brání nějakému dynamickému cvičení s hodinami GPU, zasekává jakousi proměnnou v ladění spotřeby na pevnou hodnotu. Ejhle, tady je docela dobrý rozbor. A úplně na konci to shrnuje Len Brown, jehož e-mail končí intel.com, který hlasuje dost důrazně pro přijetí tohoto patche (vlastně revertu).

Popravdě... já na to přišel teprve před týdnem, v rámci řešení zámrzů jednoho konkrétního modelu HW, po docela dlouhém zkoušení a porovnávání (mám sklad HW za zády) v Ubuntu a v Debianu s různými kernely. Zkusil jsem bay trailových kompů asi pět různých modelů a tenhle jediný vykazoval systematický problém. Samo že jsem zkusil Googlit hned jako první věc, ale zpočátku jsem asi nezkoušel správná klíčová slova... ten link na Phoronix přidal moderátor (díky), já o něm nevěděl Na uvedený kernelový bug report jsem narazil kupodivu Googlem, zároveň při štrachání ve zdrojácích kernelu (cpufreq apod.) kde jsem hledal, jak by šlo EISTem třeba trochu přidat napětí (upravit VID). Až dodatečně jsem našel několik zmínek v bubuntích fórech.

Phoronix tvrdí (a tuším i nějaké zmínky ve fórech) že údajně stejný problém má Braswell. Die-shrink CPU jádra Silvermont z 22 na 14 nm, doplněný upgradem grafiky z "generace Ivy Bridge" na "generaci Broadwell". Hm. Tak nevím co je tam za společného jmenovatele... žeby "Intel"?

[Michal Kubeček]

Len Brown, jehož e-mail končí intel.com

On i ten Mika Kuoppala má e-mail se stejnou doménou, přičemž v podstatě uvádí, že k tomu řešení se došlo na základě bisectů. Celé se to zdá potvrzovat informace agentury JPP, že u některých hardwarových vendorů jsou (interní) vývojáři linuxových driverů v pozici občanů druhé kategorie, kteří musejí škemrat o důležité informace (a často marně).

[frr]

S gustem jsem se zasmál, díky To musí být ošklivý pocit. Jsem uvnitř, chodí mi plat, ale vlastně jsem se nikam nedostal, jenom stanuji za první hradbou někde na parkáně. I tak je fajn, že takoví lidi existují, že je Intel platí aspoň za tohle, třeba jako "vyjádření dobré vůle". Pořád mají myslím blíž k jádru pudla, než my ostatní totálně venku.

[Ivan2]

Tahle presne takle to bylo i v IBM, kdyz hodne podporovala portaci Linuxu na PowerPC. U nekterych zarizeni to skoncilo to na tom ze "my jsme HW divize a my vam speficikace nedame". The bigger the company the bigger the mess.

I kdyz na druhou stranu jsem videl i situaci kdy nekdo z VMware realne dosahl toho, ze se upravila speficikace procesoru, protoze si to jako "zakaznik" vyzadali. V techhle situacich jsou hlavni motivaci penize.

[Michal Kubeček]

IBM je dost specifický případ. Na základě svých zkušeností bych to formuloval asi tak, že pokud někdo vnímá IBM jako jednu firmu, tak zcela zásadně nepochopil situaci. :-)

[kotrcka]

toto pouzivam na i5-2xxx s HD3000 a to nie je baytrail.

[k3dAR]

z jakeho duvodu? i5-2520m s HD3000 mi za 3roky nezamrzla ani jednou...

[frr]

Ivy Bridge? No fakt je, že má BayTrail od něj odvozenou grafiku. V tom kernelovém bug reportu se včera někdo ozval, že mu omezení cstate pomáhá se stabilitou na Skylaku. Přitom většina strojů z těchto rodin "prostě funguje".

Vrtá mi hlavou, jestli třeba není společný problém v tom, že výrobce motherboardu neumístil dostatečně tvrdou keramickou blokovací kapacitu do konkrétního "sladkého místa", ale až o dva centimetry dál. Že cvičení s hodinami (nevím jestli i s napětím) má za následek ostré skoky ve spotřebě, které je potřeba do určité minimální míry vykrýt filtrací napájení, jinak roste na nenulovou hodnotu riziko, že se potká motor s motorem. Pokud ten křemík zvládá násobit integery na taktu 4 GHz, reálně jsou jednotlivá hradla schopná chodit nejmíň desetkrát tak rychle. Délka vlny pár mm je relevantní. Čtvrtvlnné vedení invertuje impedanci ze zkratu na "otevřený konec". Impedanční charakteristika vysokokapacitní MLCC keramiky (desítky uF na 5V) taky není zdaleka ideální, minimum impedance je tuším někde v jednotkách MHz, tady jsme o čtyři řády výš... Osazovat tam 10nF bezindukční smetí z materiálu NP0 ? Měl by Intel přidat takové součástky dvěma řadami kolem dokola na interposer? Já nevím...

A nemám to jak otestovat, protože na rubu BGA footprintu jsou spoje na plošáku hrozně natěsno, hrst maličkých kondíků tam už je, nevím nic o jejich parametrech, o potřebných parametrech, Intel snad dokonce už ve veřejných datasheetech ani neuvádí ballout apod. S bídou se dopátrám, kde zhruba jsou ty dvě větve Vcore okolo 0.8 V (pro CPU a GPU) a 1V "uncore". V mém případě jsem zkusil přidat solid polymery, protože VRM byl celý keramický - nepomohlo to vůbec (přidal jsem na vstup i výstupy kvůli vyvážení). Jestli je to v napájení, tak je to na VF konci, v milimetrových vzdálenostech

[Ovoce]

HD3000 je Sandy Bridge (předchůdce na 32nm, tock)

[frr]

Má pravdu, předseda... tak tomu už nerozumim vůbec :-/

[frr]

Do záznamu: vypadá to, že v Linuxu počínaje vanilkou 5.3 je konečně oprava tohoto bugu. Docela zajímavé informace k tomu má commit message (link vede kupodivu na Freedesktop.org, nechce se mi dohledávat odkaz na git.kernel.org). Na kernelové bugzille se lidi baví, že to většině z nich definitivně pomohlo (a našli se asi dva, kteří říkají, že od té doby přesto nějaký pád zažili).