Mno... na enable_psr už jste si přišel sám. Mimochodem, když se přihlásíte z dálky třeba přes SSH, tak to se chová normálně? Nebo SSH konzola taky drhne?
Z obecných příčin by to jinak mohlo vypadat na nějaký problém s doručováním interruptů. Vzhledem k tomu, že nemáte procesor vytížený po strop, tak případný interrupt od myši (přesněji USB XHCI?) jde třeba někam do kanálu, a kupodivu se nestrefuje do "cizí" obsluhy... je to ale divné, tyhle moderní periferie v čipsetu dneska všechny používají message-signaled interrupty, na tom se prakticky nemá co rozbít, nejsou tam žádné sdílené linky, žádné mapování přes X kolen skrz IO/APIC apod. Pokud bych přesto chtěl podezírat nějaké problémy z tohoto soudku, mračil bych se na ACPI DSDT, a tedy bych pátral po updatu BIOSu. Případně bych se podíval na kernel cmdline argument
acpi_osi a zkusil bych říct Linuxu, ať se při interpretaci DSDT netváří jako "linux", ale jako nějaká moderní verze Windows. Konkrétně by mohlo pomoci něco jako GRUB_CMDLINE_LINUX="acpi_osi='Windows 2015'" v /etc/default/grub . Ohledně různých hodnot _OSI stringu je k dispozici
aktualizovná vysvětlivka od Microsoftu.
Ohledně zvoraných interruptů je Linux jednak dost tolerantní, jednak třeba umí nahlásit do dmesg "IRQ 21: nobody cared" a daný IRQ vstup utlumí. Čímž postižená periferie sice nezačne fungovat, ale zbytek systému zůstane živý, a o problému se dozvíte právě podle té hlášky. Případně se dá zkusit cmdline argument "irqpoll", který to na legacy drátových interruptech může ještě vyžehlit (za cenu poměrně hnusné režie, protože na každý interrupt se volají postupně všechny registrované obsluhy).
Přemejšlím, jestli by se výrazným drhnutím mohly projevovat třeba nějaké hypermoderní ultra-hluboké C-stavy. Zkusil bych třeba kernel cmdline argument intel_idle.max_cstate=1 . Jinak by se drhnutím mohly projevovat také problémy typu "PROCHOT" (ale ten by škodil i pod Windows) nebo obecně throttling (T-state) vyvolaný nějak jinak... tady je ale třeba řící, že přestože lze T-state vyvolat i na požádání softwarově, tak nevím, že by v dnešní době nějaký software tuto možnost využíval. Zrovna throttling se relativně těžko odhaluje. A "throttling jako standardní součást řešení tepla" je charakteristický spíše pro levné značky notebooků.
Alder Lake se vyznačuje tím, že jde asi o první x86 CPU (určitě první mainstreamový), který má v některých modelech kombinaci nestejně výkonných jader, tzn. big.LITTLE. Je potřeba, aby s tímto uměl pracovat scheduler. Prakticky to vyžaduje poměrně moderní jádro. Třeba v případě Debianu 11 trochu pochybuju. Do Ubuntu byla podpora Alder Lake přidána
údajně během roku 2022. Tzn. to Ubuntu, co jste zkoušel... kdy to bylo, a instalační médium bylo čerstvé? Jaká je v tom systému verze kernelu? (uname -a) Je hloupé, radit čerstvý kernel, k jehož kompilaci člověk potřebuje zdravý a výkonný počítač...
Ještě jedno vlákno ohledně různého přidrhávání a zahryzávání Linuxu na Alder Lake.
Zobrazit příspěvky
