Puncte:0

Ubuntu 21.04-21.10 Închideri aleatorii, fără jurnal

drapel tj

Hardware (hardinfo):

Sper că aceasta nu este o problemă hardware...

    OS: Ubuntu 21.10
    CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1 procesor fizic; 4 miezuri; 8 fire
    RAM: 7858608 KiB (AKA 8GB)
    Placa de baza: Lenovo YOGA 730-13IKB / LNVNB161216 (LENOVO)
    Grafică: 1920x1080 (Necunoscut) Fundația X.Org
    Stocare: (Din anumite motive nu afișează nimic, dar mi-am deschis deja computerul pentru a-l curăța pentru a remedia această problemă și am confirmat că este un SSD NVMe.
    Imprimante: (Irelevant)
    Audio: USB-Audio - Dispozitiv USB 0x46d

Simptome:

Ceea ce disprețuiesc.

Acum, de când am făcut upgrade de la Ubuntu 20.04 LTS la Ubuntu 21.04, am întâmpinat câteva blocări, aceste blocări:

  • Nu reporniți automat
  • Sunt spontane
  • Se întâmplă NUMAI când este conectat la sursa de curent alternativ
  • Nu aveți semne de logare nicăieri
  • Element din listă

Incercari:

Lucruri care nu au funcționat

Am încercat să reinstalez sistemul de cel puțin două ori (cumva am uitat, dar au fost două sau mai multe), actualizându-mă de la 21.04 la 21.10 în acest proces.De remarcat, de asemenea, am ales ce programe să fac backup, alegându-le doar pe cele care au fost:

  • Nu se instalează automat
  • Nu este local (aș putea reinstala acele datorii mai târziu)
  • Toate nu automat biblioteci de dezvoltare

Singura diferență notabilă față de 21.04 și 21.10 în accidente este niciuna (IIRC).

Alte lucruri pe care le-am incercat:

  • Actualizare BIOS
  • Reinstalare termică
  • Dezactivare c-stări (și activarea lor din nou pentru că nu ajută)
  • A încercat să nucleu de jurnal (Nu s-a putut configura corect, blocarea manuală nu a dat jurnal)
  • Înființat jurnal persistent (nu am găsit nimic de folos acolo, pot posta totuși dacă este necesar)

Suplimentar

Câteva informații suplimentare care ar putea ajuta

Ultima informație pe care o pot furniza este un fișier text, în care am scris o grămadă de lucruri pe care le-am încercat, le-am bănuit și la care am eșuat. Este foarte neorganizat (mai ales la sfârșit, când tocmai m-am iritat și am început să înjurez la sfârșitul fișierului), dar îl voi include totuși.

Înregistrare personală:

Când am actualizat la Ubuntu 21.04, lucrurile au început să meargă prost.
Presupun că schedutil face ceva, deoarece computerul se blochează uneori, fără jurnal sau nimic.
Am verificat printre altele /var/log/kern.log și nu am găsit nimic.

Bănuiesc că are legătură cu „stările P” și „stările C”.
Stările P, care reprezintă stările de performanță, sunt folosite pentru a optimiza consumul de energie în timpul execuției codului. Acestea pot fi modificate de sistemul de operare pentru a schimba tensiunea procesorului (pe scurt, modificați frecvența procesorului).
Stările C, pe de altă parte, sunt folosite pentru a optimiza/reduce consumul de energie în timpul modului inactiv (când nu este executat niciun cod).
Stările C tipice sunt:
    C0 - CPU rulează în mod activ cod (stări P)
    C1 - CPU folosește instrucțiuni HLT atunci când este inactiv, ceasul este oprit la părți ale nucleului, dar se trezește relativ rapid
    C1E - Acesta este de fapt doar C1, cu excepția cazului în care C1E este activat, procesorul scade viteza și tensiunea procesorului atunci când este în C1
    C2 și mai sus - CPU va opri diferite părți ale nucleului pentru economii mai mari de energie, cu prețul de a nu mai trezi.
Sursa: „Controlling Processor C-State Usage in Linux, O lucrare albă tehnică Dell care descrie utilizarea stărilor C cu sistemele de operare Linux”

Oricum, toate acestea se mai întâmplă acum, chiar și în 21.10, așa că aceasta trebuie să fie o problemă de kernel.
Deși setarea „intel_idle.max_cstate=0” nu oprește blocările, deci poate este o altă problemă.
Am folosit deja „memtest86” și sistemul meu este în regulă.
Voi reporni computerul și voi vedea dacă există setări de stare c în BIOS/UEFI (setările se mai numesc BIOS?).

Da, am verificat, nu am găsit nimic.

PDF-ul Dell C-state (același în sursa de mai sus) are această secțiune chiar sub cea C-states (care este prima www) numită „Verificarea utilizării C-State”. Se spune:
    Există mai multe moduri de a vedea cât timp este petrecut inactiv în diferitele C-state. 
    Mai întâi verificați mesajele kernelului de la boot (âdmesg |grep idleâ sau âgrep idle /var/log/messagesâ, de exemplu) pentru a vedea ce driver inactiv este utilizat.

Asta am primit:
    sudo dmesg |grep idle
    [sudo] parola pentru ws: 
    [ 0.028186] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
    [ 0.076265] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
    [ 0.100211] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x39a8208cdd2, max_idle_ns: 881590748921 ns
    [ 0.104538] proces: folosind mwait în firele inactive
    [ 0.128722] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
    [ 0.132319] cpuidle: folosind scara guvernatorului
    [ 0.132322] cpuidle: folosind meniul guvernator
    [ 0.389960] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
    [ 1.426615] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x396d4ffc055, max_idle_ns: 881590662783 ns
    [ 4.981048] systemd-journald[323]: varlink-22: varlink: setarea stării inactiv-server
    [ 4.981116] systemd-journald[323]: varlink-22: varlink: schimbarea stării inactiv-server â metoda-procesare
    [ 5.336734] systemd-journald[323]: varlink-22: varlink: modificarea stării processed-method â idle-server
    [ 5.339242] systemd-journald[323]: varlink-22: varlink: schimbarea stării inactiv-server â în așteptare-deconectare
Se pare că nu văd nimic aici, dar îmi amintesc în setările BIOS/UEFI ceva spunea ACPI în loc de RXS sau cum se numește.
Nu pot deschide folderul „/proc/acpi/processor/CPU0/power”, deoarece nu există (ajunge doar la „acpi”).

Un timp mai târziu, am decis să reinstalez Ubuntu și așa am făcut, lucrurile au funcționat bine în prima zi (și a doua) zi și apoi s-a prăbușit.
După ce m-am plimbat m-am hotărât să rulez „senzori de ceas”, și am descoperit ceva; când joc osu!, temperatura mea a crescut până la ~95ºC, ajungând la 99ºC!
Vreau doar să menționez că killswitch-ul PC-ului este declanșat la 100ºC, eu eram la 1 grad distanță de el și de cele mai multe ori, la 2 distanță (~96-98ºC de cele mai multe ori)!

O altă idee, aceasta poate fi o problemă cu PSU, deoarece nu am văzut-o niciodată să se prăbușească deconectată..

„kernelUpdateCrash” era numele vechi al acestui fișier, acum este „cleaningComputer”, am deschis computerul și, la naiba, era atât de multă mizerie în fani.
Nu s-a blocat de când l-am curățat! Nu prea elaborez pentru că acest fișier este atât de lung și, de asemenea, am deschis un alt computer care va fi într-o altă poveste (cred că îl voi numi "firstUbuntuInstallation").


Actualizarea sa blocat din nou.
Nu s-a întâmplat în timp ce a fost lateral, așa că cred că este o problemă cu conducerea aerului ventilatorului.
O întrebare askubuntu a avut computerul oprit din cauza încălzirii, nu sunt sigur dacă se încălzește în cazul meu, dar o actualizare a bios-ului a ajutat.
Sursa: „https://askubuntu.com/questions/1232813/ubuntu-20-04-shutdown-after-overheating”

Am făcut-o, a trebuit să pornesc pe un USB Windows PE pentru a rula programul, dar programul nu a funcționat...
Așa că, în loc să bifez opțiunea „Instalare”, am ales opțiunea „Depachetează”, și a despachetat un alt executabil cu același nume, cu excepția faptului că acum toate literele erau majuscule!
Oricum, l-am rulat și a fost această configurație ciudată și schemă care părea să folosească WinAPI pentru a pune text acolo unde nu ar trebui să fie și nu ar funcționa fără alimentare de curent alternativ.
Am continuat să-l conectez și să-l reluez, avea o imagine ciudată și probabil ruptă a unei mascote care era ca un creion?
Am atasat 2 imagini pe care le-am facut cu telefonul, de aceea aceasta poveste este intr-un folder.
PC-ul s-a repornit, a funcționat și apoi ventilatoarele au început să zbârnească de parcă lucrul avea să explodeze, nu l-am văzut niciodată așa, probabil o supratensiune temporară a ventilatoarelor în timp ce computerul încerca să se repornească.
Deci da, i-am schimbat din nou titlul.

S-a prăbușit din nou...

Ultima dată când am modificat acest fișier a fost: 2021å¹´10æ26æ¥ 19æ55å59ç§.
Acum este: 2021å¹´11æ06æ¥ 23æ10å36ç§
Tocmai am reinstalat termica, pare să funcționeze, nu sunt sigur, accelerează bine cred.
Scripturile „setPerformanceMode.sh” și „setPowersaveMode.sh” pe care le-am creat (folosind cpufreq) nu mai par să schimbe nimic.
Deci, să sperăm că funcționează, chiar dacă thermald a fost instalat implicit...
PS: Am i7z pe un terminal setat la „Always on Top”, astfel încât să pot monitoriza Frecvența, stările C și temperatura nucleelor ​​CPU (4 fizice, logice).

Bruh thermald scade la 400 MHz în timpul jocului.
Ieși din program se întoarce la 1GHz ce?
Bine, l-am făcut pe Osu! setați limita FPS la V-Sync (60fps) în loc de dublu față de aceasta (120fps, ceea ce era înainte) și pare să fie bine chiar și atunci când computerul nu este pe partea sa (de obicei nu s-a blocat când era de partea lui) , după cum subliniau fanii.

Bine, am verificat jurnalele journalctl și am primit:
„thermald.service: funcționarea schimbată -> stop-sigterm”
huh...
Așteaptă, asta e la sfârșitul jurnalului, probabil că este oprit ç¬.

Cuvinte cheie verificate cu „journalctl -g ???”:
    termic
    închiderea
    prăbușire
    panică
    scânteie
S-a prăbușit în timp ce căutam în journalctl... Să investigăm cu „journalctl -b -1”. Ultimul log este cu 4 minute înainte de accident, bine...
Da, asta este, cer ajutor în AskUbuntu, ar fi trebuit să fac asta cu mult timp în urmă!
Bine acum trebuie doar să copiez asta în întrebare.

Notă de subsol

Dacă mai sunt și alte informații pe care le-aș putea oferi, vă rog să lăsați un comentariu, le voi verifica

în mod regulat și actualizați postarea în consecință. Din nou, aceasta ar putea fi o problemă hardware, dar s-a întâmplat când mi-am actualizat sistemul și, în prezent, din cauza Wayland și a mai multor alte lucruri, nu pot face downgrade la 20.04 LTS și nu pot lucra la el.

Doug Smythies avatar
drapel gn
Vezi dacă [aici](https://askubuntu.com/questions/1373633/how-to-troubleshoot-cpu-hw-crash-in-ubuntu-18-04) și/sau [aici](https://askubuntu .com/questions/1370731/cpu-package-badly-configured-on-my-msi-laptop-how-to-reconfigure) ajută.
CattoByte avatar
drapel tj
@DougSmythies Îmi pare rău că nu am contactat, până la urmă este sezonul de examene... Oricum, voi încerca acele lucruri și apoi voi face o mulțime de sarcini intensive în resurse (care de obicei le închid), dacă funcționează, puteți posta un răspuns cu acestea și îl voi marca ca fiind cel corect.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.