Suspend na novějších distrech - NB

[BzukTuk]

Zdravím ROOT,
před zhruba dvěma měsíci jsem definitivně z notebooku vyhodil windowsy a začal používat Linux - Debian 8. Rozchodil jsem všechen HW (včetně Nvidia Optimus), ale furt se dokola jak bumerang vrací jeden zádrhel. Prosím tedy o radu, či nasměrování k vyřešení/osvětlení problému:

Po probuzení ze suspendu počítač občas zatuhne

Děje se pouze na novějších Linuxech (ověřeno na Debian 8, Fedora 22, Ubuntu 15.04 a Manjaro), na Debianu 7 a Ubuntu 14.04 se toto neděje (pár týdnů jsem Debian 7 používal na video, web, takže mnoho suspendů na noc - skutečně se problém nevyskytl ani jednou).

Jestli se probudí nebo zatuhne je zcela náhodné, občas zatuhne každé druhé probuzení, občas musím uspat a probudit 20x než to zatuhne, ale jednou to prostě zatuhne.

CTRL-ALT-Fx nefunguje, SSHčkem nevim jestli jsem se zkoušel připojit, ale pochybuju že to bude fungovat.

Není to novějším kernelem - nainstaloval jsem do Debiana 7 kernel 3.16 z backportů a nebyl problém. Debian 8 na 3.16 kernelu zamrzá.

xxx

Nakonec jsem se za použití debugovátka /sys/power/pm_trace dozvěděl že za to může ovladač drátové síťovky jme pro:
04:00.5 Ethernet controller: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller (rev 03)

Tak jsem udelal do /lib/systemd/system-sleep/remove-jme.sh

#!/bin/bash
[ "$1" = "post" ] && /sbin/modprobe jme
[ "$1" = "pre" ] && /sbin/modprobe -r jme
exit 0

A od té doby vše funguje na jedničku. Prosím o Vaše nápady, co vyzkoušet abych nemusel tento skript používat - nevím jestli to s tím úplně souvisí, ale síťový bridge pro KVM stroje (aby se virtuály na LAN tvářili jako samostaný počítač) se po probuzení ze suspendu (a přidání a odebrání modulu jme) nerozjede a pomůže jen "systemctl restart networking; ifup br0". Guest se ale už k síti nepřipojí.

NetworkManager nepoužívám, síť mám nastavenou takto:
/etc/network/interfaces

auto lo
iface lo inet loopback

allow-hotplug br0
iface br0 inet static
        address 192.168.114.143
        netmask 255.255.255.0
        network 192.168.114.0
        broadcast 192.168.114.255
        gateway 192.168.114.1
   bridge_ports eth0
        bridge_stp on
        bridge_maxwait 0
        #bridge_fd 1

Asi se budete divit, proč uspávám stroj s běžícími virtuály, no prostě to dělám :-D
Notebook je ASUS K52Jc

Díky moc za pomoc, a pokud jsem vynechal nějakou podstatnou informaci, rád doplním.

[Reklama]

[BzukTuk]

Jo a ještě doplním, že v začátcích mého zkoumání jsem zkoušel v BIOSu disablovat úplně všechno co šlo (včetně síťovky) a problém se též objevil.

Zamrznutí ve většině případů vypadá jako před uspáním, vidím kurzor myši, pozadí, displey manager.... podle toho jak to uspím (všechny možné typy pm-utils, systemd-sleep, xfce-session -suspend, uswsusp atd... jsem zkoušel, a děje se to prostě náhodně, ale s jistotou že k záseku dojde)

[Fantomas]

Tohle mi na notasu dela proprietarni ati ovladac. Jaky pouzivas ovladac na sitovku? Nejaky free nebo firmware?

[JardaP .]

Obcas zabere update BIOSu. To uz jste zkousel? Jestli tedy nejaky je.

[BzukTuk]

Nejproprietárnější věc co používám je proprietární NVidia ovladač s pomocí Bumblebee a primus. Nicméně záseky se dějí i na čistém free systému (jenom main v /etc/apt/sources.list).

modinfo jme
filename:       /lib/modules/4.1.0-0.bpo.1-amd64/kernel/drivers/net/ethernet/jme.ko
version:        1.0.8
license:        GPL
description:    JMicron JMC2x0 PCI Express Ethernet driver
author:         Guo-Fu Tseng <cooldavid@cooldavid.org>
srcversion:     E9220FEFDC704E0989588A8
alias:          pci:v0000197Bd00000260sv*sd*bc*sc*i*
alias:          pci:v0000197Bd00000250sv*sd*bc*sc*i*
depends:        mii
intree:         Y
vermagic:       4.1.0-0.bpo.1-amd64 SMP mod_unload modversions
parm:           force_pseudohp:Enable pseudo hot-plug feature manually by driver instead of BIOS. (int)
parm:           no_pseudohp:Disable pseudo hot-plug feature. (int)
parm:           no_extplug:Do not use external plug signal for pseudo hot-plug. (int)

Ten kernel 4.1 jsem doinstaloval potom, stejně to vypadá i při standartním Jessie kernelu 3.16. Na stránkách toho vývojáře http://cooldavid.org/ je git http://bbs.cooldavid.org/git/?p=jme.git a poslední verze je 1.0.8, a potom tam jsou nějaké vyšší verze bp-1.0.8.9-noasd bp-1.0.8.2 bp-1.0.8.1 bp-1.0.8. Má smysl abych se pokoušel s něčím z toho rekompilovat kernel ?

JardaP - BIOS mám nejnovější.

[Reklama]

[moutzl]

unloaduju e1000, taktez eth, pro zmenu od intelu, notebook nahodne neusinal.
v /etc/pm/sleep.d a /etc/pm/power.d
staci vytvorit dva soubory, ve sleepcat pm/sleep.d/99_e1000e_remove


#!/bin/sh

# Remove e1000e kernel module prior to suspend
rmmod e1000e


cat pm/power.d/99_e1000e_probe
#!/bin/sh

# Modprobe e1000e kernel module after resume
modprobe e1000e

[BzukTuk]

unloaduju e1000, taktez eth, pro zmenu od intelu, notebook nahodne neusinal.
v /etc/pm/sleep.d a /etc/pm/power.d
staci vytvorit dva soubory, ve sleepcat pm/sleep.d/99_e1000e_remove

Toto je způsob, kdy se používá suspend z pm_utils, a tez jsem s tim laboroval. Distribuce se systemd používají svůj suspend, a před usnutím/po probuzení se spouštějí skripty v cestě /lib/systemd/system-sleep/ s argumentem "post"/"pre". Vlastni uspavaci binarka - ExecStart=/lib/systemd/systemd-sleep suspend.

Asi budu muset do skriptu remove_jme.sh dodelat

[ "$1" = "post" ] && /sbin/modprobe jme && systemctl restart networking && ifup br0

Ale neni to pekne reseni - KVM virtualy se nechytnou a po probuzeni nebude fungovat zhruba 20 vterin sit. (Ten bridge znacne zpomaluje, ifup br0 se provede, ale konektivita jeste dalsich 15-20 vterin nejde).

Diky za pripadne dalsi napady, pokud by nekdo vedel jak se vyhnout pouzivani bridge a docilit stejne veci (Guesty dostupne z LAN, sitove nastaveni si prebirajici z DHCP, stejne jako Host) budu vdecny.
Zatim zdar

[JardaP .]

No a nejde z Debianu odstranit systemd a pouzivat nejaky normalni init? Protoze ten zasrany systemd je nejvetsi rozdil ve srovnani s temi starsimi distry, tak treba za to muze ten, respektive Poetering.

[trubicoid2]

Ale neni to pekne reseni - KVM virtualy se nechytnou a po probuzeni nebude fungovat zhruba 20 vterin sit. (Ten bridge znacne zpomaluje, ifup br0 se provede, ale konektivita jeste dalsich 15-20 vterin nejde).

no to je tim, jak mas nastaveny br0

melo by bejt:

Kód: [Vybrat]

setfd 0
sethello 10
stp off
Note
It is important to include setfd 0 and sethello 10 in order to bring the bridge interface up quickly. Other values will cause network packets to be dropped for the first 30 seconds after the bridge has become active.

https://wiki.gentoo.org/wiki/Network_bridge


jenom u stp jsem si nebyl jistej, proc to chces, ale rikaj, ze na virtualy to spis nepotrebujes

The STP option specifies whether or not the Spanning Tree Protocol should be enabled. This is essential if there is any possibility of the bridge creating a loop in the network. It is safe in other cases, but it will increase the delay between a new link being added and it being able to pass traffic. For this reason you may want to leave STP disabled in simple cases (such as when bridging a set of virtual machines to a single physical interface).

http://www.microhowto.info/howto/persistently_bridge_traffic_between_two_or_more_ethernet_interfaces_on_redhat.html

[nobody]

No a nejde z Debianu odstranit systemd a pouzivat nejaky normalni init? Protoze ten zasrany systemd je nejvetsi rozdil ve srovnani s temi starsimi distry, tak treba za to muze ten, respektive Poetering.

prvni co me napadlo (resp. nejdriv me napadlo, proboha, proc nenecha funckni 14.04 LTS, ale rekl sem si ze ma asi duvod...)
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

[BzukTuk]

trubicoid2:
Díky za odkazy, nastuduji a vyzkouším. Přiznám se, že jsem se spokojil s první konfigurací která způsobila že se na virtuály dostanu z hosta i z LAN - dál jsem nepátral co parametry přesně znamenají.
Nicméně můj dojem je, že loudování a unloadování modulu jme ten bridge vůči guestům rozbije a stejně budu muset Guesty zdlouhavě restartovat.

nobody, JardaP: Že nefunkční distra mají za společného jmenovatele systemd to vím, nechtěl jsem tu rozpoutávat flame Jsem lamka bez dostatečných zkušeností abych se dokázal rozhodnout co je ta "jediná správná unixová cesta" v otázce initu. Ubuntu se mi úplně nechce používat. Navíc to používá upstart init, a kdoví na jaké bych narazil problémy.

Kuchat z Debiana systemd se mi úplně nechce, ale asi to časem zkusím. Nejdřív bych chtěl vyzkoušet nedávno vydané "nové distro" s původním initem - nevíte o něčem co je po instalaci OOB se systVinitem a kernelem > 3.16 ? Nejlépe deb nebo rpm based. Jen na ověření že to půjde uspat a probudit bez problému. Poté bych se teprv pustil do kuchání systemd z debianu 8 a uvidělo by se jestli systemd je příčina problému.

Moc vám děkuji

[BzukTuk]

nobody:
Pěkná anti-systemd stránka. Večír vyzkouším antiX-15 z 30 června 2015
- Based on Debian Jessie, but without systemd nor systemd-shim.

[MilanK]

Na to, že se označujete za lamu a nováčka, jste v *nixu slušně v obraze. To je nějaký superlearning v alfa spánku? Také bych to potřeboval, sakra.

[trubicoid2]

Nicméně můj dojem je, že loudování a unloadování modulu jme ten bridge vůči guestům rozbije a stejně budu muset Guesty zdlouhavě restartovat.

no restartovat net a br0 budes muset, guesty asi ne, spravne nastaveny br0 te zbavi te prodlevy 20-30s

ad distro bez systemd: mam dojem, ze toto nebude chyba systemd, ale spis veci jadra; novejsi distra budou mit novejsi jadro a systemd; takze jako stary jadro sice ted pojede, ale v budoucnu se updatuje a rozbije se to

jestli je to tak, tak bych to hlasil do bugzilly kernelu; koukal jsem, ze se to u jinych sitovek resi casto, zrovna u te tve jeste ne

jeste mrkni, co je v

Kód: [Vybrat]

cat /sys/bus/pci/devices/0000:04:00.5/power/controljestli tam je auto, tak to zmen na on a koukni, jestli to nepomuze

Kód: [Vybrat]

sudo echo on > /sys/bus/pci/devices/0000:05:00.5/power/control
a jeste muzes zkusit parametr jadra pcie_aspm=off, jestli nepomuze

[trubicoid2]

tady je nejaky starsi bug, kdy se to rozbilo pri kazdem usnuti
https://bugzilla.kernel.org/show_bug.cgi?id=27692