Zapnutí úsporných režimů pro NVMe

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Já bych tomu rád přišel na kloub, ale nevím, jak. Mám pocit, že nějaké metody jsem zkusil, ale nedostal jsem se pod povrch. Určitě je víc cest, ale zase nerozumím driverům ani editaci zdrojáku jádra, abych ručně zadrátoval vypisování nějaké skryté komunikace /chyb  disku. Nebo se mi moc nechce flashovat testovací firmwary do tohoto jediného 2230 disku.

Co bych třeba ještě mohl udělat.: Je nějaká možnost jak linuxu přes cmdline parametrem říct, aby o dmesg vypisoval nějaká další diagonistická data navíc (třeba nějaká AER pcie, změny stavů nebo eventy disku-asi v součinnosti aktivací firmwarem disku).  Vím maxiálně, že je nějaká klávesová zkratky ctrl shift alt sysRq, která ukáže nějaké volby, ale to je tak všechno

A všechno tohle je časově náročné, přendavat disk do jiných PC, nechat to běžet 15 minut, kdy je jistota, jak se to chová... Různé OS a parametry spuštění...

!!! Protože stále to funguje tak, že disk se začne "cool chovat" až po nějaké době od zapnutí a pak to vydrží do nového cold startu. Ale v dmesg nic nevidím. Třeba je možné, že celá změna se odehraje v blackboxu disku a spouštěcí mechanismus je neznámý (překročení teplot v historii + kombinace aktuálního stavu linky nebo Power state), což z toho dělá neprůhledný blackbox pro mě.

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

   

• Systemd service pcie-powersave.service aktivní při startu
• ASPM L0s/L1 + L1 substates (L1.1, L1.2) povoleny

✅ Výsledek:

prosim, co je zač ta služba pcie-powersave.service? Tím myslím, co dělá, a zda to nění jen něco na úrovni powersave>policy nebo auto>power control z tohoto vlákna ale něco skutečně funkčního . Není to něco jako pani Colombová ?


Snažil jsem se to z chatGPT vytřískat vzorový soubor této služby, asi na potřetí trvalo že nechci systemctl enable ani vzor systemctl unit kde je Exec=pmsave.sh, ale mele to úplný nesmysly
[/list]

Kód: [Vybrat]

for device in /sys/module/pcie_aspm/drivers/*; do
    echo "powersave" > "$device/power/control"
doneneví která bije,, pcie_aspm nemá složku drivers ale parameters s policy= deffault/performance , power(super)save
a pro změnu power control má zase pro změnu pci device třeba z /sys/class/pci_bus/0000:00/power ... Takže asi tak  ai dělá naprvní pohled "reasonable cód", co je ale jen nefunkční puzzle. 'Jak která, asi nechci křivdit, asi jsou AI, co umí i programovat/validovaT"

je to s AI marný jedna reference je na arch linux wiki, ale taky mě to nenakoplo.

[Dushino]

[size=78%]prosim, co je zač ta služba [/size][size=78%]pcie-powersave.service[/size][size=78%]? Tím myslím, co dělá, a zda to nění jen něco na úrovni powersave>policy nebo auto>power control z tohoto vlákna ale něco skutečně funkčního . Není to něco jako pani Colombová ?[/size]

Ta pcie-powersave.service je služba udělaná jako bash skript a nedělá níc jiného, než to, bysme jinak dělali ručně. Místo startování po přihlášení uživatele to startuje po bootu systému.
Ale ono je to jedno, protože o tu službu jako takovou nejde. Důležité je vědět, co se má udělat, aby disky fungovaly, jak mají. Já to nezjistil. Resp. podařilo se mi disky přepnout do úsporného režimu, ale na teplotě se to nijak neprojevilo. Takže buď si Linux myslí, že disky do úsporného režimu přepíná a ve skutečnosti to není pravda, nebo to ten disk ignoruje a hlásí blbosti. Zatím jsem to vzdal.
Akorát je škoda, že jste nenapsal třeba včera, protože dnes ráno jsem chaty s AI promazal včetně tohoto. :-( Ve výsledku mi to aké nepomohlo, ale možná by to pomohlo vám.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

To nevadí, má důvěra v AI je na úrovni důvěry v motoristy,ale jestli vám mohu poradit je
příkaz nvme set-feature -f 0x02 -V 2 /dev/nvme0
a potomy cyklus každých x sekund nvme set-feature -f 0x02 -V 3 /dev/nvme0 = bude to cyklovat mezi stavy 23322222223222223222
hodnotu -V 2 a V 3 jsou zvolené takto: 3 je nejnižší stav a 2 je o jedničku vyšší (oparational). defacto by to fungovalo bez prvního jendorázového příkazu, jenže pak to běhalo mezi 0000033000003000033. v mém případě mezi stavem 0 a 2 nenírozdíl v spotřrbě ale ten stav 3 je dealbreaker který funguje i při vypnutém ASPM nebo ALPM. Ten stav 3 tam zjevně vydrží do další operace(zápis nebo i čtení???) Je dobré si ověřit, že  daný nastavaný stav opravdu lze nastavit  , zda get-feature  vrátí jeho hodnotu, pár sekund(hned) po set.

Mě se to naštěstí podařilo díky Janu Fikarovi částečně utlumit přes to ASPM, s tím že to "zabere" až po nějaké prodlevě po spuštění, ale po celou dobu běhu. A pak ten cyklus ubere dalších 5C.

[Dushino]

To nevadí, má důvěra v AI je na úrovni důvěry v motoristy,ale jestli vám mohu poradit je
příkaz nvme set-feature -f 0x02 -V 2 /dev/nvme0
a potomy cyklus každých x sekund nvme set-feature -f 0x02 -V 3 /dev/nvme0 = bude to cyklovat mezi stavy 23322222223222223222
hodnotu -V 2 a V 3 jsou zvolené takto: 3 je nejnižší stav a 2 je o jedničku vyšší (oparational). defacto by to fungovalo bez prvního jendorázového příkazu, jenže pak to běhalo mezi 0000033000003000033. v mém případě mezi stavem 0 a 2 nenírozdíl v spotřrbě ale ten stav 3 je dealbreaker který funguje i při vypnutém ASPM nebo ALPM. Ten stav 3 tam zjevně vydrží do další operace(zápis nebo i čtení???) Je dobré si ověřit, že  daný nastavaný stav opravdu lze nastavit  , zda get-feature  vrátí jeho hodnotu, pár sekund(hned) po set.

Mě se to naštěstí podařilo díky Janu Fikarovi částečně utlumit přes to ASPM, s tím že to "zabere" až po nějaké prodlevě po spuštění, ale po celou dobu běhu. A pak ten cyklus ubere dalších 5C.

Zajímavé, díky, vyzkouším. Mám dojem, že jsem zkoušel všechno z této diskuse, ale uvidím. Díky!

[Reklama]

[Jan Fikar]

Zajímavé, díky, vyzkouším. Mám dojem, že jsem zkoušel všechno z této diskuse, ale uvidím. Díky!

Zkoušel jste i ten ASPM UEFI enabler? To si, myslím, mohlo fungovat na tom vašem mobilním AMD, které nemá v BIOSU ASPM volbu.

https://github.com/Bootlessjam/ASPM-Tool

[Dushino]

Zajímavé, díky, vyzkouším. Mám dojem, že jsem zkoušel všechno z této diskuse, ale uvidím. Díky!

Zkoušel jste i ten ASPM UEFI enabler? To si, myslím, mohlo fungovat na tom vašem mobilním AMD, které nemá v BIOSU ASPM volbu.

https://github.com/Bootlessjam/ASPM-Tool

Ne, tohle jsem nezkoušel, protože na tom samém komplu mám i Windows a tam disk nehřeje. Resp. nehřeje tak moc, jako v Linuxu.
Ale když teď nad tím přemýšlím, možná, že Windows si něco povolují samy, šert aby se v tom vyznal. Vyzkouším i tohle.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Problém. Po 5 dnech provozu (2 LXC, LXC-docker ale jen na zkoušku to já osobně používám zřídka) se opět začal přehřívat ,teplot 85/69 °C ne contoleru a flashi. asi to začlo od noci, ráno jsem si toho všiml. opět v dmesg nic. nepomohl podobné skripty a triky co jsem si dal do /etc/rc.local. ani nvme reset ani echo 1> /sys...device/pci/3:0/reset... A dochází i k přehřívání i přesto, že běžína pozadí cyklus-skript zapisující 0x03 powerstav od 0x02 featury


Netuším čím by to mohlo být, jen jsem instaloval mod-gui-sensors pro proxmox(aby v node-summary ukazal víc údajů včetně teploty nvme) a opět pak odinstaloval. Ten balík od autora Molix nebo Milolix /shellový script s parametrem install/uninstall) využívá a potřeboval stáhnout balík sensors. Ale i potom jsem balík odinstaloval....

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

No a teď spontánně přestal topit. Já fakt nevím čím to je....  Jenom sem šverchal s  LAN kabelem. Mám pocit, jako když je tam nějaký watch nebo nízká hustot IRQ/eventů

opět nic za půl hod v dmesg.  !
Ovšem je tu jedna brutální zvláštnost. po dobu kdy ssd topilo  powertop  ukazoval na druhém tabu : C-stavy, že cpu je 30-50% v C2 stavu,  40% v C8 ...


nyní: netopí (33/18°C -důvod je přidání větráku, že to je nižší než normálních 45/30) a powertop hlásí:  C2 5% ,,,C10 70% , C8 5%


TAdy se děje fakt něco divnýho... ty etapy veder trvají tak asi max 4 hodiny a mám podezření, že PC nějak krvácí na nedostaktu eventů:
# dmesg --color=always  |grep -vPi "enp2|audit|veth|layfs|vmbr|cifs|redirect" # abych no našel lépe

Kód: [Vybrat]

[pá 31 19:22:] perf: interrupt took too long (2511 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[pá 31 20:24: ] perf: interrupt took too long (3139 > 3138), lowering kernel.perf_event_max_sample_rate to 63000
[pá 31 21:45: ] perf: interrupt took too long (3990 > 3923), lowering kernel.perf_event_max_sample_rate to 50000
[pá 31 22:27: ] perf: interrupt took too long (4992 > 4987), lowering kernel.perf_event_max_sample_rate to 40000
[čt   n6 03:22: ] perf: interrupt took too long (6254 > 6240), lowering kernel.perf_event_max_sample_rate to 31000

Kde ale zjistím čemu interrupt patřil??? (ani grep -C 3 perf:" neodhalil okolí) Zvláštní je, že už kdysi jsem nabýval podezřejní, že pokud manipuluj s PC ,zapojuju USBčka, ethernet kabel, dojde k ukončení přehřívání lépe (v době ,kdy jsem měl za to, že už opětovně se už nezačně přehřívat, když jednou přestane)

ALE: timestampy perf řádků z dmesg nekorelují z přehříváním (5.11. večer až asi 22h, 6.11 doteď), , timestamp tam je 6.11 v 3 hodiny (což by mohlo zahrnovat pokud se to stalo od půlnoci), ale přechozí 2 jsou z 31.10. 3 hodiny po bootu, kdy se určitě nezahříval

čili 2 věci :?
perf: interrupt took long je co zač
package při topení je v C2 stavu (cores si idlují vesele v C10)