Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: BzukTuk 02. 09. 2015, 19:52:14
-
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.
-
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)
-
Tohle mi na notasu dela proprietarni ati ovladac. Jaky pouzivas ovladac na sitovku? Nejaky free nebo firmware?
-
Obcas zabere update BIOSu. To uz jste zkousel? Jestli tedy nejaky je.
-
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/ (http://cooldavid.org/)je git http://bbs.cooldavid.org/git/?p=jme.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ší.
-
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
-
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
-
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.
-
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:
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 (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 (http://www.microhowto.info/howto/persistently_bridge_traffic_between_two_or_more_ethernet_interfaces_on_redhat.html)
-
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
-
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
-
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.
-
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.
-
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 cat /sys/bus/pci/devices/0000:04:00.5/power/controljestli tam je auto, tak to zmen na on a koukni, jestli to nepomuze
sudo echo on > /sys/bus/pci/devices/0000:05:00.5/power/control
a jeste muzes zkusit parametr jadra pcie_aspm=off, jestli nepomuze
-
tady je nejaky starsi bug, kdy se to rozbilo pri kazdem usnuti
https://bugzilla.kernel.org/show_bug.cgi?id=27692 (https://bugzilla.kernel.org/show_bug.cgi?id=27692)
-
[...]
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 (http://www.abclinuxu.cz/zpravicky/ubuntu-14.04.3)
-
jeste me napadlo nastavit eth0, aby cekalo na wake-on-lan, pak eth0 neusina uplne, coz by mohlo mozna pomoct
sudo ethtool -s eth0 wol g
-
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
-
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
-
Vetsinou se to dává do rc.local, ale nevim, spis najdi, kde se to zapne a zrus to.
-
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.
-
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
-
nevim, kde by se to mohlo zapinat :(
co to najit bruteforce?
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
-
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/ (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:
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 :)
-
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 pcie_aspm=off a 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
-
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é.
-
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 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
-
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
-
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 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:
#USB powersaving
for i in /sys/bus/usb/devices/*/power/autosuspend
do
echo 1 > ${i}
done
#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)
-
Suspend (na notesu) mi nikdy nefungoval, vždycky se ten notes uspal tak, že už jsem ho ničim "neprobudil". A jak pak notesy přestaly mít hw tlačítko na power on/off, stávalo se to čím dál zábavnější.
Ale toto se dělo před hodně dávnou dobou, od té doby jsem tuto funkčnost nikdy ani nezkoušel zapínat, opravdu už nemám čas si hrát s každou takovou pitomostí. Která by měla fungovat ouf-of-the-box (když už to funguje v těch widlích, na tom samém železe).
Nicméně, tento příspěvek do fóra mne přinutil to zase zkusit, schválně, esli budu konečně příjemně překvapený.
Takže jsem minulý týden při odchodu z práce nastavil:
Power manager / Extended / Advanced options / Set computer inactivity sleep-mode: Suspend
(Hibernate mi to ani nepovolilo)
A šel jsem domů.
No a druhý den po příchodu do práce - hádejte!
Notes tuhej, na žádnou klapku nereagoval, nezapnulo ho "power" tlačítko na šasi, ani na dockině, po bezradném bušení do kláves (připadal jsem si jako v jednom Kubrickově filmu) jsem vytáhl kabel od dockiny z notesu a asi půl hodiny držel to "power" na notesu.
Naštěstí to naskočilo a na nic si to nestěžovalo.
Závěr:
Na to, že píšeme rok 2015, to je hodně tristní.
PS: ano, zkusím poškádlit strejdu googla, když už jsem se s tím rozhodl ztrácet čas, ale koho to má pořád bavit?
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
$ uname -a
Linux ... 3.13.0-63-generic #103-Ubuntu SMP Fri Aug 14 21:42:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$
----
Thinkpad Edge E540
-
Suspend (na notesu) mi nikdy nefungoval, vždycky se ten notes uspal tak, že už jsem ho ničim "neprobudil". A jak pak notesy přestaly mít hw tlačítko na power on/off, stávalo se to čím dál zábavnější.
Ale toto se dělo před hodně dávnou dobou, od té doby jsem tuto funkčnost nikdy ani nezkoušel zapínat, opravdu už nemám čas si hrát s každou takovou pitomostí. Která by měla fungovat ouf-of-the-box (když už to funguje v těch widlích, na tom samém železe).
Nicméně, tento příspěvek do fóra mne přinutil to zase zkusit, schválně, esli budu konečně příjemně překvapený.
Takže jsem minulý týden při odchodu z práce nastavil:
Power manager / Extended / Advanced options / Set computer inactivity sleep-mode: Suspend
(Hibernate mi to ani nepovolilo)
A šel jsem domů.
No a druhý den po příchodu do práce - hádejte!
Notes tuhej, na žádnou klapku nereagoval, nezapnulo ho "power" tlačítko na šasi, ani na dockině, po bezradném bušení do kláves (připadal jsem si jako v jednom Kubrickově filmu) jsem vytáhl kabel od dockiny z notesu a asi půl hodiny držel to "power" na notesu.
Naštěstí to naskočilo a na nic si to nestěžovalo.
Závěr:
Na to, že píšeme rok 2015, to je hodně tristní.
PS: ano, zkusím poškádlit strejdu googla, když už jsem se s tím rozhodl ztrácet čas, ale koho to má pořád bavit?
Ted jsem resil nejake laptopy a zajimave, ze na jednom laptopu suspend fungoval bezvadne na debianu a po prechodu na ubuntu suspend nejde. Obvykle cekam nutnost doladeni ze strany debianu, ale tentokrat to bylo presne naopak, ubuntu zklamalo na cele care (nejen v jedne veci) s jedinou vyjimkou, upstart funguje lepe nez systemd (tedy prozatim pouze v jednom pripade).
-
asi zalezi jak na SW tak na HW. me to naopak s fedorou chodilo temer vzdy,
i kdyz ted treba na desktopu po probuzeni ze suspendu jsou uplne zmatene barvy (integrovanej intel - predtim na propietarnich nvidia ovladacich to nedelalo).
a na notasu zase po probuzeni nejde psat do chromu, ale staci alt+tab a uz to jde.
aktualne
4.1.6-100.fc21.x86_64
ale FC22 jela taky
-
trubicoid:
uz jsem projel jeden (první) průchod příkazem badblocks -s -w /dev/sdb. Trvalo to 14 hodin, a někdy mezi 8:58 až 9:30 to naházelo při testu čtení zapsaných dat 466 errorů. Zítra to spustím znovu, uvidíme jestli se přealokovalo, nebo si budu muset hrát s umístěním partition a této "půlhodině" se vyhýbat.
Koukám že default -b je 1024 a -c je 64. Zvětšením těchto hodnot se rychlost průchodu asi zvěčí - zítra spustím a uvidím jestli vyskočí podobné množství chyb (to by ale asi stejně bylo menší kvůli rozdílným parametrům b a c) nebo jestli se všechno realokovalo.
fedorac, Fantomas, hawran:
Jojo změny v distrech, kernelech a kdovívčem. Fakt nenávidím ty HW výrobce že všechno po***aj už v samotném BIOSu, ACPI, UEFI a kdovíkde jinde na tý nejvíc HW úrovni, jen ať tam ty Windows choděj a BFU si nestěžuje... Až budu mít chvilku nainstaluju znova Debiana 7, s kterým jsem vůbec žadný problém s ničím neměl a pořádně to otestuju (až na ten hibernate, ten rači jen párkrát, nebo moc psychuju z opotřebení SSDčka?). Protože pokud změnou z debianu 7 na 8 se něco takto domrví, asi by o tom měl debian team vědět. (zatím jsem na netu nikdy (krom tohoto threadu a jednoho mailu) své linuxové problémečky neřešil - vůbec nevím kam psát, koho prudit aby bug report padl na úrodnou půdu).
Jediné co jsem zkoumal byl Cčkový zdroják toho jme ovladače a mezi kernely 3.2 a 3.16 se lišil jen parametry pro preprocesor, které nastavovali různé věci různě pro různé kernely, samotný kód mi přišel nezměnen (i verze ovladače stejná) - ale zavlečenou chybu v kernelu jsem už téměř vyloučil.
hawran:
Zkoušel jste: /sys/power/pm_trace ? https://wiki.ubuntu.com/DebuggingKernelSuspend (https://wiki.ubuntu.com/DebuggingKernelSuspend) Tato věcička (která je naštěstí přítomna v ubuntím kernelu - debian defaultně nemá - možná v debug balíku?) mi správně napověděla že suspendovací problém je v síťové kartě, tedy spíše v jejím ovladači jme. I když nevím jestli nastavení toho HW timeru se nerozbije Vaším způsobem oživení po suspendu :) (vyndání baterky...)
-
trubicoid:
uz jsem projel jeden (první) průchod příkazem badblocks -s -w /dev/sdb. Trvalo to 14 hodin, a někdy mezi 8:58 až 9:30 to naházelo při testu čtení zapsaných dat 466 errorů. Zítra to spustím znovu, uvidíme jestli se přealokovalo, nebo si budu muset hrát s umístěním partition a této "půlhodině" se vyhýbat.
Koukám že default -b je 1024 a -c je 64. Zvětšením těchto hodnot se rychlost průchodu asi zvěčí - zítra spustím a uvidím jestli vyskočí podobné množství chyb (to by ale asi stejně bylo menší kvůli rozdílným parametrům b a c) nebo jestli se všechno realokovalo.
no to nech dojet do konce, pise postupne 4 ruzny paterny 55, AA, FF a 00 a uz v druhym kole by melo byt chyb min. Jestli na konci nebude 0, tak disk nema cenu uz pouzivat
bezi to i nekolik dni no, zalezi na disku. -b 4096 kvuli novym diskum, ktery maji interne 4k bloky, ale navenek to treba nereknou a -c 4096 podstatne zrychli kontrolu
jeste malej trik, zkontroluj hdparm -W 1 /dev/sdx, to taky zrychluje badblocks
taky bych to nedelal pres USB, ale pres SATA nebo e-SATA, ten USB mass-storrage se strasne dlouho vzpamatovava z chyby a taky to bude o dost dyl trvat
bych klidne disk dal zpet do laptopu a pustil systemrescuecd
-
Dík za info Trubicoide:
připojím HDD v rámečku k raspberry pi (snad elektrika bude dostatečná a nespálim si to) někam do sklepa a nechám to ject třeba měsíc. (nemám způsob jak zapojit 2,5 palcový disk do standartních SATA konektorů do normálního počítače - v HW ohledu jsem sto let za opicema, "kacířská" technologie SSD je v mém HW parku novinka, sata disky jsem začal vnímat cca před rokem :) a hned sem začal nadávat na ty nové Lkové konektory - zlatý IDE, zlatej MOLEX - už se mi povedlo narvat to SATA napájecí Lko obráceně a zrušit si jeden konektor - naštěstí jsem si všimnul a nezapnul to do elektriky )
Dnes ráno mi to zas po probuzení ze suspendu vytuhlo - když jsem včera znovu testoval parametry pro jádro pcie_aspm tak jsem cvičně zakomentoval vypnutí WoL a zapomněl jsem to vrátit :)
-
Tak výhoda SATAn je, ze kabely do 3,5" das i do 2,5"
S tou malinou to bude super pomaly, ale vyhoda je, ze ti to nebude blokovat pocitac. Kdyz bys měl na stále zapnutým počítači volný jedno sata, tak by to bylo rychlejsi.
Na maline mozna -c 4096 vytece z pameti, tak mensi cislo
-
...
Notes tuhej, na žádnou klapku nereagoval, nezapnulo ho "power" tlačítko na šasi, ani na dockině, po bezradném bušení do kláves ...
PS: ano, zkusím poškádlit strejdu googla, když už jsem se s tím rozhodl ztrácet čas, ale koho to má pořád bavit?
...
UPDATE:
Takže, po vygůglení/přečtení https://askubuntu.com/questions/489912/thinkpad-does-not-wake-from-sleep-14-04 (https://askubuntu.com/questions/489912/thinkpad-does-not-wake-from-sleep-14-04) a po provedení "disable USB 3.0 in the BIOS" už se ten notebook zmátoří.
Taky mohu provést update BIOSu...
(tím pádem toto asi nebyl zrovna problém linuxu)
-
No vidíš, nestačilo by teda rmmod xhci před suspendem a lsmod xhci po probuzení a v bájosu to nechat zaplý? (samozřejmě v případě, že je xhci jako modul)
-
No vidíš, nestačilo by teda rmmod xhci před suspendem a lsmod xhci po probuzení a v bájosu to nechat zaplý? (samozřejmě v případě, že je xhci jako modul)
asi myslis:
# pred suspendem
modprobe -r xhci
# po probuzeni
modprobe xhci;)
-
No vidíš, nestačilo by teda rmmod xhci před suspendem a lsmod xhci po probuzení a v bájosu to nechat zaplý? (samozřejmě v případě, že je xhci jako modul)
asi myslis:
# pred suspendem
modprobe -r xhci
# po probuzeni
modprobe xhci;)
no týýý kráááso.. hele, rmmod normálně použávám, ale s tím lsmodem to je úlet, asi to chce víc koukat, jaký blbosti píšu :D
-
rmmod je tupej, nezahazuje unused dependency moduly, proto je lepsi pouzit modprobe -r...
ostatne rmmod (http://linux.die.net/man/8/rmmod) to ma primo ve svem man description ;)
DESCRIPTION
rmmod is a trivial program to remove a module (when module unloading support is provided) from the kernel.
Most users will want to use modprobe(8) with the -r option instead.
-
suspend fungoval bez problemu i drive na Fedora 21.
provedl jsem upgrade na nejnovejsi distro .. stacilo dnf distro-sync na verzi 22, pak 23.
# uname -r
4.2.2-300.fc23.x86_64
jedna se o beta verzi - asi mesic do vydani ( https://fedoraproject.org/wiki/Releases/23/Schedule (https://fedoraproject.org/wiki/Releases/23/Schedule) )
suspend funguje stale.
Ke zvazeni.
-
No vidíš, nestačilo by teda rmmod xhci před suspendem a lsmod xhci po probuzení a v bájosu to nechat zaplý? (samozřejmě v případě, že je xhci jako modul)
asi myslis:
# pred suspendem
modprobe -r xhci
# po probuzeni
modprobe xhci;)
no týýý kráááso.. hele, rmmod normálně použávám, ale s tím lsmodem to je úlet, asi to chce víc koukat, jaký blbosti píšu :D
Tak určitě.
Přesně z tohodle důvodu mám ten notebook na pracovním stole...
(ale dík za snahu)
-
Zdarec, tak tento bug byl uspesne vyresen patchem ovladace jme. V kernelu by se mel patch objevit ve verzi 4.6. Uplnou nahodou v tom teda nema prsty Lennart, ale nejspise default nastaveni pm_async na 0 v non-systemd distribucich (zatim jsem toto neoveril).
Vice info zde
https://lkml.org/lkml/2016/2/23/450
Jeste jednou diky za navedeni k docasnemu reseni, ktere mi umoznovalo notebook pouzivat
-
Dobrý, píšu si malé bezvýznamné plus ;)