Problém s usínáním

ctibi · listopad 29, 2011, 7:58am

Zdravím, po mnoha měsících víceméně bezvadného fungování s Fedorou 15 se najednou objevil problém, který dost znepříjemňuje práci: stává se mi často, že se počítač prostě nenechá uspat. Když dám Uspat, obrazovka zhasne, několik vteřin to šrotuje a pak zase všechno najede jako při probuzení. Jediné, co se dá dělat, je počítač restartovat. Ale poté usínání stejně funguje jen chvíli, po cca 5-10 uspáních se problém vynoří zase.
Nevím bohužel, kdy se přesně problém poprvé objevil, ale mám pocit, že to nijak nesouvisí s žádnou aktualizací.
Mám notebook PackardBell EasyNote NJ65, Intel Pentium T4200, 2GB RAM, grafika integrovaná Intel… Systém mám vcelku aktualizovaný, ale jak říkám, dříve se nic takového nedělo.

Díky za rady

tady připojuji výpis logu jednoho takového neúspěšného uspání:

Nov 29 07:46:41 ctibi NetworkManager[8943]: sleep requested (sleeping: no enabled: yes)
Nov 29 07:46:41 ctibi NetworkManager[8943]: sleeping or disabling…
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): now unmanaged
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): device state change: activated -> unmanaged (reason ‘sleeping’) [100 10 37]
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): deactivating device (reason ‘sleeping’) [37]
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): canceled DHCP transaction, DHCP client pid 16882
Nov 29 07:46:41 ctibi kernel: [162759.395335] cfg80211: Calling CRDA to update world regulatory domain
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): cleaning up…
Nov 29 07:46:41 ctibi NetworkManager[8943]: (wlan0): taking down device.
Nov 29 07:46:41 ctibi avahi-daemon[806]: Withdrawing address record for 10.0.0.34 on wlan0.
Nov 29 07:46:41 ctibi avahi-daemon[806]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.0.0.34.
Nov 29 07:46:41 ctibi NetworkManager[8943]: (eth0): now unmanaged
Nov 29 07:46:42 ctibi avahi-daemon[806]: Interface wlan0.IPv4 no longer relevant for mDNS.
Nov 29 07:46:42 ctibi avahi-daemon[806]: Withdrawing address record for fe80::226:5eff:fe5f:b8b0 on wlan0.
Nov 29 07:46:42 ctibi NetworkManager[8943]: (eth0): device state change: unavailable -> unmanaged (reason ‘sleeping’) [20 10 37]
Nov 29 07:46:42 ctibi NetworkManager[8943]: (eth0): cleaning up…
Nov 29 07:46:42 ctibi NetworkManager[8943]: (eth0): taking down device.
Nov 29 06:46:41 ctibi dbus: [system] Activating service name=‘org.freedesktop.nm_dispatcher’ (using servicehelper)
Nov 29 07:46:42 ctibi kernel: [162759.583267] cfg80211: World regulatory domain updated:
Nov 29 07:46:42 ctibi kernel: [162759.583271] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Nov 29 07:46:42 ctibi kernel: [162759.583275] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.583278] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.583281] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.583285] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.583288] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.587049] cfg80211: Calling CRDA for country: CZ
Nov 29 07:46:42 ctibi kernel: [162759.593373] cfg80211: Regulatory domain changed to country: CZ
Nov 29 07:46:42 ctibi kernel: [162759.593377] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Nov 29 07:46:42 ctibi kernel: [162759.593380] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.593383] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2301 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.593386] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Nov 29 07:46:42 ctibi kernel: [162759.593389] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
Nov 29 06:46:42 ctibi dbus: [system] Successfully activated service ‘org.freedesktop.nm_dispatcher’
Nov 29 07:46:44 ctibi kernel: [162761.605981] PM: Syncing filesystems … done.
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: The canary thread is apparently starving. Taking action.
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: Demoting known real-time threads.
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: Successfully demoted thread 8567 of process 8557 (/usr/bin/pulseaudio).
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: Successfully demoted thread 8566 of process 8557 (/usr/bin/pulseaudio).
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: Successfully demoted thread 8557 of process 8557 (/usr/bin/pulseaudio).
Nov 29 06:47:04 ctibi rtkit-daemon[1531]: Demoted 3 threads.
Nov 29 07:47:04 ctibi kernel: [162761.776286] Freezing user space processes … (elapsed 0.01 seconds) done.
Nov 29 07:47:04 ctibi kernel: [162761.787151] Freezing remaining freezable tasks …
Nov 29 07:47:04 ctibi kernel: [162781.789117] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze, wq_busy=0):
Nov 29 07:47:04 ctibi kernel: [162781.789138] khugepaged S f38a9eb4 0 29 2 0x00800000
Nov 29 07:47:04 ctibi kernel: [162781.789143] f38a9ec4 00000046 00000002 f38a9eb4 f4e088a4 f38a9e64 c0b299c0 f38a0290
Nov 29 07:47:04 ctibi kernel: [162781.789150] c0b299c0 96b6dda0 0000940c 00000000 0000940c f38a0000 0100000a c0a86340
Nov 29 07:47:04 ctibi kernel: [162781.789157] f38a9e84 c0466348 00000286 f38a9e90 c07f9e2e f38a9edc 09af45e2 09b030dd
Nov 29 07:47:04 ctibi kernel: [162781.789169] Call Trace:
Nov 29 07:47:04 ctibi kernel: [162781.789180] [] ? arch_local_irq_save+0x12/0x17
Nov 29 07:47:04 ctibi kernel: [162781.789186] [] ? _raw_spin_lock_irqsave+0x10/0x27
Nov 29 07:47:04 ctibi kernel: [162781.789190] [] ? _raw_spin_unlock_irqrestore+0x13/0x15
Nov 29 07:47:04 ctibi kernel: [162781.789194] [] ? __mod_timer+0x109/0x114
Nov 29 07:47:04 ctibi kernel: [162781.789198] [] schedule+0x4d/0x4f
Nov 29 07:47:04 ctibi kernel: [162781.789201] [] schedule_timeout+0x8a/0xb7
Nov 29 07:47:04 ctibi kernel: [162781.789204] [] ? del_timer+0x61/0x61
Nov 29 07:47:04 ctibi kernel: [162781.789208] [] schedule_timeout_interruptible+0x1a/0x1c
Nov 29 07:47:04 ctibi kernel: [162781.789213] [] khugepaged+0xc0/0xba8
Nov 29 07:47:04 ctibi kernel: [162781.789217] [] ? remove_wait_queue+0x2c/0x2c
Nov 29 07:47:04 ctibi kernel: [162781.789221] [] ? add_mm_counter.constprop.4+0x11/0x11
Nov 29 07:47:04 ctibi kernel: [162781.789224] [] kthread+0x67/0x6c
Nov 29 07:47:04 ctibi kernel: [162781.789228] [] ? kthread_worker_fn+0x11d/0x11d
Nov 29 07:47:04 ctibi kernel: [162781.789232] [] kernel_thread_helper+0x6/0x10
Nov 29 07:47:04 ctibi kernel: [162781.789339]
Nov 29 07:47:04 ctibi kernel: [162781.789341] Restarting tasks … done.
Nov 29 07:47:04 ctibi kernel: [162781.847923] video LNXVIDEO:00: Restoring backlight state

petrherynk · listopad 29, 2011, 9:12am

Já měl něco podobného snouveau driverem, než jsem přešel na nvidii. Protože nemám Tvou kartu, těžko poradím.

yarda · listopad 29, 2011, 2:27pm

Nemáte aktivní nějaký nfs mount?

ctibi · listopad 29, 2011, 2:43pm

ntsf disk mám, ale nemám ho připojený a ani jsem ho nikdy v poslední době nepřipojoval…

yarda · listopad 29, 2011, 5:07pm

Takový backtrace jsem zatím neviděl Podobný problém se vyskytoval při uspávaní s aktivním nfs mountem, což však není Váš případ.

Jakou máte verzi kernel?

uname -r

Zkuste zakázat TH pomocí:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Toto nastavení vydrží do rebootu. Dejte vědět, zda to pomůže.

ctibi · listopad 29, 2011, 6:00pm

Jádro mám 2.6.41.1-1.fc15.i686. Ok, děkuju za radu, dám vědět, jestli to pomůže, až se zase ten problém vynoří…

yarda · listopad 30, 2011, 12:47pm

Každopádně doporučuji tento problém nahlásit do bugzilly na komponentu kernel. Výše uvedený workaround může snížit výkon systému.

ctibi · prosinec 3, 2011, 9:12am

Tak se vynořil, zatím jednou, a vaše rada skutečně pomohla, děkuju. Uvidím, jestli to bude fungovat i nadále. (A po probuzení jsem zase onu hodnotu čehosi nastavil na always, jak to bylo předtím, tak snad to výkon systému nesníží… Ale můžete mi aspoň nějak velmi stručně říct, co jsem tím vlastně udělal?)

yarda · prosinec 3, 2011, 12:31pm

Stručně řečeno: velké stránky umožňují překonat dřívější limit 4kB na stránku, čímž se sníží režie správy paměti, khugepaged defragmentuje paměť, aby bylo možné alokovat nové velké stránky. Váš problém bude mít asi nějakou souvislost s tímto procesem (viz poskytnutý backtrace), ale nemusí to být příčina. Velké stránky lze vypnout zápisem never, změna se projeví jen pro nově spuštěné procesy. Zároveň dojde k ukončení khugepaged, always opět zapne. Více v kernel dokumentaci, např:
http://www.mjmwired.net/kernel/Documentation/vm/transhuge.txt

Ohlašte tento problém do bugzilly, pokud tam neodhalí přímou příčinu, tak minimálně bude tento problém trackován.

Jinak jako dočasný workaround si můžete udělat pm-hook (skript který se vykonává před uspáním a po probuzení), který umístíte do /etc/pm/sleep.d, syntaxí se můžete inspirovat např. v /usr/lib64/pm-utils/sleep.d/49bluetooth či dalšími skripty v tomto adresáři.