înregistrare Logare
Puncte:2
Roman Bekkiev avatar Ubuntu

Nu se poate suspenda: sistemul se reia dintr-un motiv necunoscut după ~40 de minute de somn

drapel pl
Roman Bekkiev

Am cumpărat noul MSI Summit B15 care a fost furnizat fără sistem de operare și instalat cu bucurie pe el proaspăt Ubuntu 21.04. Până acum totul funcționează destul de bine (cu excepția unor probleme cu touchpad și fără drivere pentru scanerul FP, dar asta este o poveste diferită), cu excepția unei probleme destul de enervante: când încerc să suspendez aparatul, se trezește brusc în aproximativ 40-60 de minute și începeți să rulați ventilatoarele la viteză maximă. Nu numai că uneori se trezește pe mine dacă s-a întâmplat să dorm în apropiere, se consumă bateria peste noapte, făcând suspendarea practic inutilă.

Am încercat să dezactivez totul (vezi Aici cum) dar butonul de pornire intră /proc/acpi/wakeup, așa că în prezent arată așa:

â ~ cat /proc/acpi/wakeup | grep activat
PWRB S4 *platformă activată:PNP0C0C:00

Nu ajută.

Aici este o parte din syslog (aici am pus sistemul să se suspende la 7:48 și a început să se aprindă la 8:35, dar m-am autentificat mai târziu, abia la 10:56):

5 septembrie 07:48:00 rb-base tracker-store[6784]: OK
5 septembrie 07:48:00 rb-base systemd[3246]: tracker-store.service: Succeeded.
5 septembrie 07:48:01 rb-base kernel: [ 146.937861] Blocare: systemd-logind: hibernarea este restricționată; vezi man kernel_lockdown.7
5 septembrie 07:48:05 rb-base kernel: [ 150.972633] Blocare: systemd-logind: hibernarea este restricționată; vezi man kernel_lockdown.7
5 septembrie 07:48:05 rb-base kernel: [ 150.977982] Blocare: systemd-logind: hibernarea este restricționată; vezi man kernel_lockdown.7
5 septembrie 07:48:05 rb-base ModemManager[2119]: <info> sistemul [sleep-monitor] este pe cale să se suspende
5 septembrie 07:48:05 rb-base kernel: [ 150.997219] wlo1: deautentificare de la b0:4e:26:31:82:b8 prin alegere locală (Motiv: 3=DEAUTH_LEAVING)
Sep 5 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-DISCONNECTED bssid=b0:4e:26:31:82:b8 motiv=3 local_generated=1
Sep 5 07:48:05 rb-base NetworkManager[1931]: <info> [1630817285.6861] device (wlo1): modificarea stării: dezactivare -> deconectat (motiv „sleeping", sys-ifac
e-state: „gestionat”)
5 septembrie 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-SIGNAL-CHANGE deasupra=0 semnal=0 zgomot=9999 txrate=0
5 septembrie 07:48:07 rb-base systemd[1]: Atins ținta Sleep.
5 septembrie 07:48:07 rb-base systemd[1]: Începe suspendarea...
5 septembrie 07:48:07 rb-base kernel: [ 152.341436] PM: suspendă intrarea (s2idle)
5 septembrie 07:48:07 rb-base systemd-sleep[7072]: Sistem de suspendare...
5 septembrie 07:48:07 rb-base systemd[1]: zsysd.service: Reușit.
5 septembrie 07:48:07 rb-base kernel: [ 152.424613] Sincronizarea sistemelor de fișiere: 0.083 secunde
5 septembrie 10:56:42 rb-base kernel: [ 152.426323] Înghețarea proceselor din spațiul utilizatorului... (a trecut 0,002 secunde) gata.
5 septembrie 10:56:42 rb-base kernel: [ 152.428515] OOM killer dezactivat.
Sep 5 10:56:42 rb-base kernel: [ 152.428516] Înghețarea sarcinilor înghețate rămase... (a trecut 0,001 secunde) finalizată.
5 septembrie 10:56:42 rb-base kernel: [ 152.429676] printk: Suspendarea consolei (utilizați no_console_suspend pentru a depana)
5 septembrie 10:56:42 rb-base kernel: [ 153.214718] ACPI: EC: întrerupere blocată
5 septembrie 10:56:42 rb-base kernel: [11468.660690] ACPI: EC: întrerupere deblocata
Sep 5 10:56:42 rb-base kernel: [11469.338032] nvme nvme0: 8/0/0 default/read/poll queues
5 septembrie 10:56:42 rb-base kernel: [11469.574414] OOM killer activat.
Sep 5 10:56:42 rb-base kernel: [11469.574416] Repornirea sarcinilor... gata.
5 septembrie 10:56:42 rb-base kernel: [11469.584884] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound (bound) [0000:00:16.0] 0000:00:16.0
5 septembrie 10:56:42 rb-base kernel: [11469.586402] thermal thermal_zone6: nu s-a putut citi zona termică (-61)
5 septembrie 10:56:42 rb-base systemd[1]: Verificarea stării a dus la omisia lucrărilor Run anacron.
5 septembrie 10:56:43 rb-base systemd-sleep[7072]: Sistemul a fost reluat.
5 septembrie 10:56:43 rb-base kernel: [11469.846714] PM: suspendare ieșire
5 septembrie 10:56:43 rb-base systemd[1]: systemd-suspend.service: Reușit.
5 septembrie 10:56:43 rb-base systemd[1]: Suspendare terminată.
5 septembrie 10:56:43 rb-base systemd[1]: Sleep țintă oprit.
5 septembrie 10:56:43 rb-base systemd[1]: Suspendare țintă atinsă.
5 septembrie 10:56:43 rb-base systemd[1]: Suspendare țintă oprită.
5 septembrie 10:56:43 rb-base NetworkManager[1931]: <info> [1630828603.2303] manager: sleep: trezire solicitată (dormire: da activat: da)
5 septembrie 10:56:43 rb-base ModemManager[2119]: sistemul <info> [sleep-monitor] se reia
5 septembrie 10:56:43 rb-base NetworkManager[1931]: <warn> [1630828603.5154] sup-iface[499bce01c63427b3,1,wlo1]: call-p2p-cancel: eșuat cu P2P anulat eșuat
5 septembrie 10:56:45 rb-base ModemManager[2119]: <info> [base-manager] nu a putut verifica suportul pentru dispozitivul „/sys/devices/pci0000:00/0000:00:14.3”: nu este acceptat de orice plugin
5 septembrie 10:56:46 rb-base dbus-daemon[1927]: [sistem] Se activează prin systemd: service name='net.reactivated.Fprint' unit='fprintd.service' solicitat de către ':1.90' (uid= 1000 pid=3490 comm="/usr/bin/gnome-shell " label="unconfined")
5 septembrie 10:56:46 rb-base systemd[1]: Se pornește Daemonul de autentificare cu amprentă...
5 septembrie 10:56:46 rb-base dbus-daemon[1927]: [sistem] Serviciul „net.reactivated.Fprint” a fost activat cu succes
5 septembrie 10:56:46 rb-base systemd[1]: Daemonul de autentificare cu amprentă a pornit.

(Iată jurnalul complet, în cazul în care am eliminat ceva relevant)

După cum puteți vedea, nu există nicio înregistrare în momentul în care aparatul este de fapt trezit. Deci următoarea mea presupunere este că ceva din afara sistemului de operare provoacă trezire. Dar sistem arata nesuspendat: de ex. monitorul este aprins și ecranul de conectare este afișat imediat când deschid capacul, de obicei durează ceva timp pentru a porni ecranul de autentificare, când deschid capacul la sistemul de dormit.

UPD1: Datorită comentariului @David, deși WOL în sine nu este relevant pentru sistemul meu (MSI Summit nici măcar nu are o placă Ethernet), mi-am dat seama că trebuie să caut o configurație în configurarea BIOS. Și am găsit acolo intrarea „Wake on Thunderbolt⢠device” care era activată. Am 0 dispozitive Thunderboltâ¢, dar am dezactivat intrarea, pentru orice eventualitate. Acest lucru nu a ajutat totuși.

UPD2: Se pare că /proc/acpi/wakeup pur și simplu nu funcționează: așa cum am menționat mai devreme, am dezactivat totul, cu excepția butonului de pornire din el, totuși, când deschid capacul, computerul încă se trezește.

UPD3 Scriptul de descărcare a stării bateriei, așa cum sugerează @sancho.s Reinstalați MonicaCellio:

#!/bin/bash

TIME="$(data +'%y-%m-%d %H:%M:%S')"
CAPACITY="$(cat /sys/class/power_supply/BAT1/capacity)"
CURRENT="$(cat /sys/class/power_supply/BAT1/current_now)"
VOLTAGE="$(cat /sys/class/power_supply/BAT1/voltage_now)"

echo "$TIME\t$CAPACITY\t\t\t$CURRENT\t$VOLTAGE" >> /home/rb/bat_dump
332
1 + 3
msi
David avatar
drapel cn
David
Acest lucru ar putea fi de ajutor. https://superuser.com/questions/86576/how-does-wol-wake-on-lan-work a fost problema pentru unii în trecut.
0
Răspunde
sancho.s ReinstateMonicaCellio avatar
drapel pl
sancho.s ReinstateMonicaCellio
Deconectați mouse-ul/receptorul BT?
0
Răspunde
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
Am încercat să deconectez tot ce ar putea fi deconectat. =)
0
Răspunde
Nate T avatar
drapel it
Nate T
Niciunul dintre loggeri nu va afișa fiecare jurnal (de care știu eu, dar unul poate avea o opțiune care o are.) De obicei, fiecare se concentrează pe un aspect specific al sistemului (de exemplu, `dmesg` tipărește jurnalele legate de boot.) Aș `cd ` la `/var/log` și `cat` fiecare se termină în `.log` pe rând. Căutați un jurnal care are o intrare pentru aproximativ 8:00 și care este vinovatul. Unele dintre intrările (cum ar fi `apt`) vor fi directoare cu jurnalele înăuntru.Sau ai putea fi creativ cu `grep`. Ceva de genul `cat /var/log/**.log | grep `.
0
Răspunde
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
Vot închide această întrebare, deoarece această problemă este cel mai probabil legată de hardware și pare să nu poată fi rezolvată din sistemul de operare Ubuntu
1
Răspunde
Puncte:4
sancho.s ReinstateMonicaCellio avatar Ubuntu
drapel pl
sancho.s ReinstateMonicaCellio

Nu știu dacă acesta este cazul dvs., dar dacă sistemul dvs. este configurat să dorm când închideți capacul și să hiberneze după 40 de minute, ventilatoarele pot porni în acel moment, când hibernează. Totuși, asta nu ar explica consumarea bateriei. Un alt caz înrudit este atunci când sistemul este configurat să hiberneze la un anumit nivel de baterie. Deci drenarea bateriei are loc mai întâi (nu aș ști de ce), iar asta declanșează hibernarea. Sau, este posibil ca sistemul să nu fie suspendat deloc.

Diagnosticarea stării PC-ului

Verificați evenimentele relevante cu

$ journalctl --no-pager | pisica -n | grep -A 10 -B 3 systemd-logind

Puteți identifica suspendări în rânduri, cum ar fi

9818455 sep 08 22:25:57 MyServer systemd-logind[1132]: Capacul închis.
...
9818624 sep 09 06:43:47 MyServer systemd-logind[1132]: Capacul deschis.

Sau folosiți

$ cat -n /var/log/syslog | grep -A 10 -B 3 systemd-logind

Ta syslog pare să arate un somn eficient, dar nu sunt sigur. eu am PM: suspendă intrarea (profundă) (într-un Thinkpad) în loc de dvs PM: suspendă intrarea (s2idle). Vezi și mai jos.

Diagnosticarea consumului de baterie

Ai putea scrie un scenariu, să zicem dump_bat.sh acea elimină starea bateriei a dosar, cu ceva de genul

#!/bin/bash
upower -i /org/freedesktop/UPower/devices/battery_BAT0 > battery_$(data | tr " " "_").txt

Ai putea grep anumite părți ale rezultatului, cum ar fi procent, timpul de golire, actualizat, și Istorie fragmente. Tine minte

$ chmod +x dump_bat.sh

Plasarea unui job cron pentru a face acest lucru la fiecare zi 10 minute va ajuta la identificarea modelul de descărcare a bateriei și starea notebook-ului (treaz/dormit). Adăuga

*/10 * * * * <calea către dump_bat.sh>

cu

$ crontab -e

Evitarea scurgerii bateriei

Încercați să dezactivați WOL cu acest

$ ethtool -s <dispozitiv> wol d

Combinați cu diagnosticul de mai sus.

0 + 3
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
sancho.s Reinstalați MonicaCellio, mulțumesc pentru răspuns! Drenarea bateriei în sine nu este o problemă: este de așteptat ca ventilatoarele care funcționează toată noaptea vor descărca o baterie. Referitor la WOL: Nu cred că este relevant, așa cum am spus, laptopul meu nici măcar nu are ethernet (doar `lo` și `wlo1` apar în `ip a`), deci, nici un `ethtool`.
0
Răspunde
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
În ceea ce privește `hibernare`, există totuși ceva ciudat: `systemctl hibernate` spune `Failed to hibernate system via logind: Sleep verb "hibernate" not supported`, deci, nu cred că este suportat. Totuși, în `syslog` există înregistrări care arată ca `Lockdown: systemd-logind: hibernarea este restricționată; vezi man kernel_lockdown.7`. Totuși, acestea nu sunt aproape de suspendare a evenimentelor.
0
Răspunde
sancho.s ReinstateMonicaCellio avatar
drapel pl
sancho.s ReinstateMonicaCellio
@RomanBekkiev - Ideea din spatele sugestiei mele nu este evitarea drenării bateriei, ci, așa cum am spus, învățarea modelului de drenare a bateriei și starea notebook-ului (treaz/dormit). Vă rugăm să încercați sugestia și să postați rezultatele.
0
Răspunde
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
Ei bine, așa cum mă așteptam, se pare că partea din sistem în care se află cron nu funcționează, așa cum se întâmplă cu jurnalele.Aici este depozitul: https://gist.github.com/RB-Lab/b2246e7dc47b16d603b943d1a4a17be9 Aici laptopul se încarca până la 22:30, apoi am deconectat încărcătorul și l-am pus în suspendare. Iar următoarea înregistrare apare abia dimineața următoare, când am deschis capacul și m-am autentificat, 20% deja folosit. Se pare că sistemul nu se trezește noaptea, ci doar are un somn prost...
0
Răspunde
sancho.s ReinstateMonicaCellio avatar
drapel pl
sancho.s ReinstateMonicaCellio
@RomanBekkiev - Comentariile mele: 1) Ce vrei să spui prin „partea sistemului în care se află cron nu funcționează”? Se pare că și-a făcut treaba. Dacă nu ai făcut-o altfel. 2) Ce vrei să spui prin „cum se întâmplă cu buștenii”? 3) „Jurnalul bateriei” dumneavoastră arată perfect normal. 4) Cât de des apare problema pe care o descrieți? Nu s-a întâmplat ieri.
0
Răspunde
Roman Bekkiev avatar
drapel pl
Roman Bekkiev
Se pare că sistemul de operare în sine **este** în modul suspendare, prin urmare cron nu își execută joburile și nu este scris nimic în jurnale. Lucrul care rulează ventilatoare probabil undeva într-un strat de abstractizare inferior (de exemplu, BIOS?). Nu cred că scăderea cu 20% a capacității la 8 ore este OK: de ex. Mac-urile folosesc cel mult 3-5% din capacitatea bateriei pe noapte, când sunt în modul de repaus, iar Lenovo ThinkPad-ul meu anterior avea o utilizare comparabilă a bateriei. Cu toate acestea, problema, probabil, nu este legată de Ubuntu/Linux.
0
Răspunde
sancho.s ReinstateMonicaCellio avatar
drapel pl
sancho.s ReinstateMonicaCellio
@RomanBekkiev - Ok, acum înțeleg ce vrei să spui. Comentariile mele: 1) Decalajul din raportul bateriei este complet de așteptat și confirmă că computerul este suspendat. Nu înseamnă că este ceva în neregulă cu cron sau log-uri, este exact așa cum ar trebui să funcționeze. 2) Cât despre o scădere de 20% peste noapte, asta nu înseamnă că nici nu este ceva în neregulă. Din OP-ul original, am înțeles că bateria era complet epuizată peste noapte. Ar fi ciudat.
0
Răspunde
sancho.s ReinstateMonicaCellio avatar
drapel pl
sancho.s ReinstateMonicaCellio
3) Dacă 20% poate fi îmbunătățit, ați putea încerca câteva lucruri. a) Verificați cu Windows, dacă ați instalat. b) Încercați să eliminați modul de suspendare Sx și să utilizați un alt mod, dacă este posibil. c) Activați hibernarea, dacă este posibil, în sistemul dumneavoastră. Toate acestea merită încă o întrebare/e. 4) Vă sugerez să continuați să utilizați scriptul pentru a vedea cum se comportă computerul. 5) Dacă nu ați prins un caz când au pornit fanii, aceasta ar putea fi o problemă suplimentară.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.