Suspend na novějších distrech - NB

nobody

Re:Suspend na novějších distrech - NB
« Odpověď #15 kdy: 03. 09. 2015, 16:04:42 »
[...]
Navíc to používá upstart init, a kdoví na jaké bych narazil problémy.
[...]
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. [...]

upstartu u *buntu se neni duvod bat, je kompatibilni s sysvinit kterej rozsiruje o vlastnosti pro ktere vznikl puvodne systemd (tedy v puvodnim jen init) jako pri startu pousteni sluzeb paralelni/zavislostni, automaticke restartovani sluzeb pri padu, zobrazeni stavu...

*buntu 14.04 neni sice posledni verze, ale jde o LTS vydani s podporou (3-)5let, a vychazi subverze kde je povyseno jadro a xorg prevzate z posledniho NeLTS *buntu vydani po nekolika mesicich odladeni, aktualne je mesic stara subverze 14.04.3 s jadrem (3.19) a xorg z 15.04 viz u sousedu


trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #16 kdy: 05. 09. 2015, 10:29:26 »
jeste me napadlo nastavit eth0, aby cekalo na wake-on-lan, pak eth0 neusina uplne, coz by mohlo mozna pomoct

Kód: [Vybrat]
sudo ethtool -s eth0 wol g

BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #17 kdy: 05. 09. 2015, 21:02:07 »
Vypnout stp pomohlo - konektivita již nikde nevypadává.

Antix mi jako distribuce moc do oka nepadnul - myslím že suspendy všechny proběhli v pohodě, ale nejsem si tím úplně jistej - nepovedlo se mi rozchodit KVMko kvůli nějaký chybějící GTK3 a SPICE věci, a nechtělo se mi s tím dál drbat. Poté jsem pomocí návodu od nobodyho zkousel debian bez systemd , KVMko se mi opět nepovedlo rozchodit tentokrát kvůli závislostem. Zkoušel jsem tedy na tom debianu non-systemd suspend tedy jen tak z pro legraci, a stějně se to kouslo, jen trošku jinej průběh to mělo.

ethtools eth0 z nějakého důvodu je nastavene na probouzení po síti (g - magic packet) defaultne. Zkusil jsem to vypnout - jiz patnactkrat jsem s takto nenaslouchajici sitovkou suspendnul a zatim vse jede. Tedy děkuji trubicoide za nasměrování do směrů, které by mě nenapadli. Doufám že vše bude OK, ale již jsem byl přesvědčenej o vyřešení problému tolikrát :-) za chvíli mi asi od samého testování odejde disk :) Mel bych delat pokusy z fleshky nebo tak... i kdyz disk by asi stejně dostával čočku.

Du systém chvíli používat a uvidíme jestli se časem kousne.

Ještě zjistím jestli na starejch distrech je naslouchání síťovky na wol defaultně vypnuté (což bych očekával). Pak se někdy pokusím zjistit jestli tento fígl zabere na Fedoře 22, kde jsem měl subjektivně nejhorší suspendí výsledky. Ale až budu mít jakous takous jistotu (tejden používání) že to funguje.

Prozatím díky

BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #18 kdy: 06. 09. 2015, 18:58:06 »
cat /lib/systemd/system-sleep/sleep_workarounds.sh
#!/bin/bash

if [ "$1" = "post" ] ; then
VNM=`cat /tmp/running_vm.lst`
for vm in $VNM; do virsh resume $vm; done
rm /tmp/running_wm.lst
fi

if [ "$1" = "pre" ] ; then
virsh list | grep running | tr -s ' ' | cut -d " " -f 3 > /tmp/running_vm.lst
VNM=`cat /tmp/running_vm.lst`
for vm in $VNM; do virsh suspend $vm; done
ethtool -s eth0 wol d
fi
exit 0

Pomoci tohodle skriptíčku pauznu virtuály, a vypnu WOL - suspend funguje, zhruba 40 suspendu proběhlo bez záseků, virtuály pokračují v pingání tam kde skončily, žádný síťový divnosti - jsem megaspokojenej :)

Poslední co mě trápí je hibernate. Při znovuspuštění počítače po hibernate síťovka zas naslouchá na magic packet a opět náhodně to při probouzení zamrzne. Potřebuji tedy spustit "ethtool -s eth0 wol d" ještě před tím než se nahrne swap do ram. Pokud někdo víte jak způsobit aby se při "initramfs-tools -u" do initrd.img vlozil i ethtool a ve správnou chvíli nastavil síťovku prosím poraďte/nasměrujte. Už jsem si rozbalil initrd.img a hledám kde je v něm větev co zpracovává právě resume po hibernaci, ale zatím nic nenacházím.

(V BIOSu není nastavení pro disable WOL )

Díky všem

Trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #19 kdy: 06. 09. 2015, 23:31:22 »
Vetsinou se to dává do rc.local, ale nevim, spis najdi, kde se to zapne a zrus to.


BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #20 kdy: 07. 09. 2015, 00:08:28 »
Právě se obávám že to nebude tak jednoduché - do hibernace jdu s nastaveným WOL na d, ale po znovuzapnutí notebooku je WOL opět na g. Při suspendu WOL na d vydrží, a k záseku nedojde. Budu zkoumat dál, až bude čas a dám vědět.

nobody

Re:Suspend na novějších distrech - NB
« Odpověď #21 kdy: 07. 09. 2015, 02:38:41 »
zkus vytvorit udev pravidlo co okamzire pri nahozeni eth driveru vypne wol, viz (tedy obracene):
https://wiki.archlinux.org/index.php/Wake-on-LAN#With_udev

trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #22 kdy: 07. 09. 2015, 11:02:58 »
nevim, kde by se to mohlo zapinat  :(
co to najit bruteforce?

Kód: [Vybrat]
sudo find /etc -type f -exec grep -i 'ethtool' {} \;
a pak to nahlasit prislusne distribuci; neni normalni, ze se auto-magically zapina wol na sitovce, obzvlast u notebooku (kde bych ani necekal funkcni wol hw implementaci) a taky kvuli spotrebe dokonce i ve vypnutym stavu s aktivnim wol

BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #23 kdy: 07. 09. 2015, 18:16:25 »
trubicoid2
Já se obávám že to je šmejdskou síťovkou, která i v době kdy je počítač zapnutý naslouchá, dokud to nepřebiju. Ostatně to není první problém co s touto síťovkou řeším. Na windowsech (i při dřívějších pokusech na Linuxu) mi po připojení ke switchi dovolila fungovat jen na 100Mbitech a i ty jsem musel vynutit (vypnout auto-negotiation, natvrdo nastavit 100mbit full duplex), oproti jiným zařízením (jiným switchům nebo tak) fungovala na 1Gbps. (https://thefrozenfire.com/2011/09/jmicron-jmc250-gigabit-nic-speed-issue-in-linux/). Tento problém jsem ale vyřešil výměnou Zyxel Switche za Cisco Linksys wifi router. (Na kabelech nezáleží - jen na typu zařízení ke kterému připojuji - jen jednou mi jel gigabit oproti starému switchi - to byla bouřka, hrál jsem si s ethtool a do restartu se Gigabitové spojení chytlo... sám se tomu divím, možná jsem měl halucinace, ale dal bych ruku do ohně že se to takto stalo).

Hm... koukám že v /etc je o ethtoolu dost zmínek - mrknu na to a dám vědět.

Že by byla chyba v distribuci si úplně nemyslím - stejně se to chovalo na Fedoře 22, Ubuntu 15.04, a Manjaru, ale v době zkoušení jsem ještě netušil že za vše může síťovka, natož naslouchání WOL. (Musím nainstalovat tu Fedoru konečně, a ověřit že alespoň ten suspend bude fungovat.... grr nemam čas na nic)

nobody:
Díky vyzkouším - ale obávám se že to způsobí pouze vypnutí naslouchání síťovky při startu systému. Při resume se značná část startu systému vynechává, ale mohu se mýlit. Vyzkouším a dám vědět.


Co mě ale nejvíce zaráží je že při disable síťovky v BIOSu problémy se suspendem přetrvávají....

Díky pánové že se mnou ztrácíte čas

nobody

Re:Suspend na novějších distrech - NB
« Odpověď #24 kdy: 07. 09. 2015, 19:49:44 »
nobody:
Díky vyzkouším - ale obávám se že to způsobí pouze vypnutí naslouchání síťovky při startu systému. Při resume se značná část startu systému vynechává, ale mohu se mýlit. Vyzkouším a dám vědět.

pri resume se ozivujou a nacitaj udev pravidla pro usb(+wlan), ale myslel sem ze jeste provadis "modprobe (-r) jme" pri kterem by se prave udev pravidla nacitali i pro net/eth* a to zda se uz si vypustil :)

trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #25 kdy: 08. 09. 2015, 13:18:02 »
Co mě ale nejvíce zaráží je že při disable síťovky v BIOSu problémy se suspendem přetrvávají....

to nejspis vypne sitovku jen pro potreby biosu, tedy PXE treba, ale v linuxu se zase aktivuje

ja si myslim, ze HW bude asi osizenej, ale WOL sam tezko zapina, spis bych myslel, ze bude osizenej tak, ze WOL nakonec vubec nebude umet

to ze to neni HW je zrejme z toho, ze stare distribuce fungovali

na Ubuntu LTS 14.04 mi to bruteforce najde jen dva soubory /etc/network/if-pre-up.d/ethtool a /etc/network/if-up.d/ethtool, ale nic je asi nepouziva. Jeste jsem zapomnel v tom grepu je lepsi -iH

a co ten
Kód: [Vybrat]
pcie_aspm=off a
Kód: [Vybrat]
cat /sys/bus/pci/devices/0000:04:00.5/power/controlabysme neco nepodcenili :)


jeste potom by byla asi moznost misto eth pouzit wlan, ne? navic wlan muzes lehce vymenit

BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #26 kdy: 08. 09. 2015, 22:36:12 »
cat /sys/bus/pci/devices/0000\:04\:00.5/power/control
on

a s parametrem off se to chovalo stejně.

Jo máš pravdu, na kvalitu síťovky to svádět nemohu, ale pěkně mě vytáčí. zbytek notebooku je překvapivě suprovej - furt sleduju co nabízej novýho shopy ale že bych dostal něco výrazně lepšího za podobný prachy prachy co jsem do toho před lety dal, to se říct nedá.

Teď nemám úplně čas tu hibernaci řešit, suspend zatím ani jednou nesklamal od tý doby co vypínám WOL. Až budu mít čas si zase hrát, vyzkouším si udělat custom initramfs s ethtoolem a vypnout WOL jakmile to bude možné.


trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #27 kdy: 09. 09. 2015, 11:05:15 »
cat /sys/bus/pci/devices/0000\:04\:00.5/power/control
on

a s parametrem off se to chovalo stejně.

bud on, nebo auto, off to nema :) auto jako kdyby vic setri elektriku a usina zarizeni, jsou s nim ale problemy; on je tedy spravne


a co ten pcie_aspm=off? je to parametr jadra, takze nekde do /etc/default/grub do GRUB_CMDLINE_LINUX_DEFAULT a pak nejaky update-grub, nebo jak to v distribuci mas; pripadne jednorazove proste po restartu v grubu (drzis shift, pak das e a dopises to na konec, pak ctrl+x)

a pro jistotu mrknes, co rika bez toho parametru a s nim
Kód: [Vybrat]
dmesg | grep -i aspm
toto ridi zase usporu energie vsech pcie zarizeni a treba tvoje eth ma toto nalomeny (treba hlasi, ze to podporuje a neni to pravda)
totiz toto se menilo a starsi distibuce spis aspm nezapinaji a novejsi spis zapinaji

BzukTuk

Re:Suspend na novějších distrech - NB
« Odpověď #28 kdy: 20. 09. 2015, 12:45:05 »
Zdravím, omlouvám se že reaguji takto pozdě, neměl jsem přes samou práci čas řešit uživatelské "drobnůstky" :)

trubicoid:
Jojo, přesne takto jsem to myslel - z příkazu "cat /sys/bus/pci/devices/0000\:04\:00.5/power/control" mi leze "on" defaultně.
A když jsem přes grub dopsal jako parametr kernelu pcie_aspm=off (a pak ještě zkontroloval přes cat /proc/cmdline) tak se to chovalo stejně.

Když není nastaven parametr pcie_aspm=off tak
"dmesg -i ASPM" vypíše:
[    0.273162] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.473557] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.473886] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[    0.544510] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.544514] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    1.400566] jme 0000:04:00.5: can't disable ASPM; OS doesn't have ASPM control
[    2.504064] ath: phy0: ASPM enabled: 0x43

"cat /proc/cmdline" vypíše:
BOOT_IMAGE=/boot/vmlinuz-4.1.0-0.bpo.1-amd64 root=UUID=bla-bla-ble ro quiet

Pokud pci_aspm=off nastavim tak:
"dmesg | grep -i ASPM" vypise:
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-0.bpo.1-amd64 root=UUID=3f01e8d5-53ef-4732-b2cd-e18280df8395 ro pcie_aspm=off quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-0.bpo.1-amd64 root=UUID=3f01e8d5-53ef-4732-b2cd-e18280df8395 ro pcie_aspm=off quiet
[    0.000000] PCIe ASPM is disabled
[    0.272738] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.473204] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
[    0.536088] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[    2.454148] ath: phy0: ASPM enabled: 0x43

"cat /proc/cmdline"
BOOT_IMAGE=/boot/vmlinuz-4.1.0-0.bpo.1-amd64 root=UUID=3f01e8d5-53ef-4732-b2cd-e18280df8395 ro pcie_aspm=off quiet

A SUSPEND hned na první pokus zakousl systém.

Nezkoušel jsem zkombinovat pcie_aspm=off a přenastavovat /sys/bus/pci/devices/0000\:04\:00.5/power/control na auto.

Tedy pokud to shrnu tak:
SUSPEND (do RAM) funguje bezvadně, když před uspáním spustím "ethtool -s eth0 wol d" (disabluji WoL)
HIBERNATE (do swap oddílu) nefunguje - stále se to občas kousne, protože nedokážu disablovat WoL předtím, než se začne nahrávat swap partition do RAM.

Jak jsem prorokoval HDD po mnoha a mnoha suspendech začal podle smartu chybovat:
SMART error (OfflineUncorrectableSector) detected on host
tak jsem pořídil SSDčko - s ním snad testy suspendu nebudou tolik mlátit. Původní disk připojuji přes rámeček a používám na dočasná nedůležitá data (např. stahování z internetu kde je zápis na SSD zbytečný) a tady mám opět další problémy - při suspendu se HDD stále točí... To je ale na jiný thread, a zatím jsem neudělal dostatečný průzkum - SSDčko mám teprv druhý den. (jediné co zatím tak nějak zabralo a neporouchalo suspend je unbindnout veškeré usb zařízení před samotným suspendem - ale to se mi úplně nelíbí - třeba najdu systémovější řešení)

Dík

trubicoid2

Re:Suspend na novějších distrech - NB
« Odpověď #29 kdy: 21. 09. 2015, 09:27:16 »
aha, tak aspm to nebude, ale uz bez toho parametru se tvuj notebook tomu aspm brani, coz neni z hlediska spotreby optimalni

muzes kvuli spotrebe zkusit navic k tomu zakazani wol i toto: pcie_aspm=force (je mozny, ze se objevi jina nestabilita, ale spis proste jenom v biosu je spatne napsana podpora aspm)

a k tomu jeste
Kód: [Vybrat]
echo powersave > /sys/module/pcie_aspm/parameters/policy
no a ten ramecek na externi hdd mas usb3 nebo usb2? ty usb3 se mi vypinali, ale meli externi napajeni

pripadne jedno z tohoto:

Kód: [Vybrat]
#USB powersaving
for i in /sys/bus/usb/devices/*/power/autosuspend
do
        echo 1 > ${i}
done

Kód: [Vybrat]
#Runtime PM
for i in $(find /sys -name control | grep power | grep usb )
do
        echo auto > ${i}
done

no a ten disk zazalohuj ddrescue a pak ho prejed badblocks -b 4096 -c 4096 -svw, voni se ty necitelny sektory tim zapisem prealokuji a disk zase nejakou dobu funguje (nekdy, ne vzdy)