On 2013-11-23 18:33, Álvaro Castillo wrote:

Buenas a todos,

Seguro que este mensaje os suena por haber publicado uno similar lo que estaba dentro del proyecto Tumbleweed, del cuál me salí. No entiendo muy bien como se define el concepto "rolling release" ahí porque según me comentaron en el hilo que hice sobre este asunto. Me decían que actualizáse a 13.1 y luego volviera a enviar el mensaje. Y ya luego se creó un poco un hilo sobre qué concepto trae Tumbleweed.

La Tumbleweed es un derivado de factory que se construye a partir de la distribución "current" y unos cuantos paquetes más modernos procedentes de factory. Los repositorios "current" son en realidad un enlace simbólico a la versión estable más moderna de la distro. Hace dos semanas apuntaban a la 12.3, y ahora apuntan a la 13.1. Usando "tumbleweed" se supone que estás haciendo "zypper dup" todas las semanas; por tanto, en cuanto cambian los enlaces automáticamente, sin hacer nada especial por tu parte, el "zypper dup" te cambia a la 13.1, porque los repos especiales de Tumbleweed están a cero. Eso es lo que te ha dicho Greg. ¿Lo entiendes ahora? -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2013-11-23 a las 18:41 -0600, cheperobert escribió:

El 23/11/13, Álvaro Castillo <> escribió:

Supongo que esta de mas, pero por las dudas:

como root, ejecutar "pm-suspend", para ver como se comporta.

Tienes razón, buena idea. He estado mirando el hilo en factory, y el bugzilla, especificamente los logs, y falta información. Dices (Álvaro) que no suspende, pero explicas detalles. ¿Suspende y no despierta? ¿Suspende? ¿Se cae? Los detalles son importantes. En el log veo: suspend initiated: Fri Nov 22 16:20:25 WET 2013 2013-11-22T16:20:24.949880+00:00 linux-ojbq dbus[614]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' 2013-11-22T16:20:24.951767+00:00 linux-ojbq systemd[1]: Started Network Manager Script Dispatcher Service. 2013-11-22T16:20:25.065466+00:00 linux-ojbq systemd[1]: Starting Sleep. 2013-11-22T16:20:25.065918+00:00 linux-ojbq systemd[1]: Reached target Sleep. 2013-11-22T16:20:25.066249+00:00 linux-ojbq systemd[1]: Starting Suspend... 2013-11-22T16:20:25.095221+00:00 linux-ojbq systemd-sleep[1849]: Suspending system... 2013-11-22T16:22:05.437130+00:00 linux-ojbq rsyslogd: [origin software="rsyslogd" swVersion="7.4.6" x-pid="645" x-info="http://www.rsyslog.com"] start 2013-11-22T16:22:05.437263+00:00 linux-ojbq systemd[1]: Mounting Huge Pages File System... lo cual parece indicar que se cuelga en algún punto después de iniciar la suspensión, pero cual no lo se, porque el log no se puede guardar. Edita "/etc/suspend.conf": #suspend loglevel = 2 #max loglevel = suspend loglevel = 255 ... #splash = y splash = n Es decir, aumentar los detalles del registro y desactivar los gráficos monos, hay que ver el texto. Saca un vídeo con una cámara puesta en un trípode si puedes. Prueba con pm-suspend, y también con pm-hibernate. Es más fácil hibernar a disco que a ram. Eso de momento. Luego, si tienes otro ordenador, estudiamos si es posible volvar el registro a otro ordenador (el ordenador que suspende no puede escribir en disco el registro a partir de cierto momento. Y no desvies el tema en factory hacia que es tumbleweed o no, o pierdes la oportunidad de que el desarrollador te atienda: se aburririrá y se olvidará del asunto. Y aprende a no responder encima (top-posting), y a recortar los quotes de los mensajes, o te mandan a la porra. No bromeo, es más importante de lo que piensas. - -- Saludos Carlos E. R. (desde 12.3 x86_64 "Dartmouth" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlKRaRoACgkQtTMYHG2NR9WPlQCeIyknJylI6bv1L/v8EHvZUqWC mtcAninfehc92DoJg2/P78G/fsr7zhVg =EfJS -----END PGP SIGNATURE-----

El día 24 de noviembre de 2013 02:48, Carlos E. R. escribió:

Dices (Álvaro) que no suspende, pero explicas detalles. ¿Suspende y no despierta? ¿Suspende? ¿Se cae? Los detalles son importantes.

Pues simplemente no vuelve a iniciarse la interfaz gráfica, no se ilumina la pantalla como si fuera a realizar un arranque gráfico o algo. Simplemente no despierta solo se iluminan los LEDs de Bloq Mayús y el Wi-Fi.

Es decir, aumentar los detalles del registro y desactivar los gráficos monos, hay que ver el texto. Saca un vídeo con una cámara puesta en un trípode si puedes.

Prueba con pm-suspend, y también con pm-hibernate. Es más fácil hibernar a disco que a ram.

He probado con ambos, ahora obtengo un log resultante de haber hecho pm-hibernate que adjunté a este mensaje pero ni si quiera se "apaga" el ordenador, básicamente no hiberna porque se queda como "cogido". Aquí tengo el vídeo de pm-hibernate que he grabado con mi móvil. http://www.youtube.com/watch?v=7kM-AUBNIbg Y este es con pm-suspend. http://www.youtube.com/watch?v=qnau7KDdYDU

Eso de momento. Luego, si tienes otro ordenador, estudiamos si es posible volvar el registro a otro ordenador (el ordenador que suspende no puede escribir en disco el registro a partir de cierto momento.

Si tengo una OLPC ¿te vale?

Y no desvies el tema en factory hacia que es tumbleweed o no, o pierdes la oportunidad de que el desarrollador te atienda: se aburririrá y se olvidará del asunto. Y aprende a no responder encima (top-posting), y a recortar los quotes de los mensajes, o te mandan a la porra. No bromeo, es más importante de lo que piensas.

Si lo entiendo. Disculpas jeje

El día 24 de noviembre de 2013 07:10, Pinguino Patagonico escribió:

El día 23 de noviembre de 2013 14:33, Álvaro Castillo escribió:

...

Buenas a todos,

Seguro que este mensaje os suena por haber publicado uno similar lo que estaba dentro del proyecto Tumbleweed, del cuál me salí. No entiendo muy bien como se define el concepto "rolling release" ahí porque según me comentaron en el hilo que hice sobre este asunto. Me decían que actualizáse a 13.1 y luego volviera a enviar el mensaje. Y ya luego se creó un poco un hilo sobre qué concepto trae Tumbleweed.

Bueno al lío, hice una instalación limpia a 13.1 (sin meterme en Tumbleweed), y la suspensión no me funciona. Únicamente con el kernel que me funcionó por defecto fue con el 3.7.10-1.16-desktop.

Mientras que cuando usaba 12.3 y Tumbleweed, los kernels kernel-desktop-3.11.6-33.1.gf7498bf.x86_64 y kernel-desktop-3.12.0-34.2.ge8fa6b4.x86_64 no funcionaba la suspensión en RAM.

Ahora con 13.1 lo mismo, el kernel actual es: 3.11.6-4-desktop.

¿Qué podría ser... a efectos es el kernel...? Aquí adjunto los siguientes logs:

- Xorg.0.log - dmesg - lsusb -v - lspci -v - cpuinfo - pm-suspend.log - messages (/var/log) - Lista de software instalado

El hilo del bug lo he abierto en el siguiente enlace (en inglés): https://bugzilla.novell.com/show_bug.cgi?id=851873

Donde configuraste lo relativo al manejo de energía, apagado y suspensión?

Pregunta elemental... --

Lógico, el sistema, "no sabe que hacer", "si no le dices como hacerlo" http://en.opensuse.org/SDB:Suspend_to_RAM http://forums.opensuse.org/english/get-technical-help-here/applications/4851... Pero parece que para la 13.1 ha cambiado: https://news.opensuse.org/2013/11/19/opensuse-13-1-ready-for-action/ a new suspend power state for devices, experimental dynamic power management for all Radeon GPUs since r600 (disabled by default due to stability concerns) System Tools Thanks to integration of udev in the latest systemd the labeling of ethernet devices has become persistent across reboots. In the power management area, there is a new suspend power state for devices which can deal with extremely low power states (or have issues with the other suspend states) and, perhaps more relevant for laptop users, experimental dynamic power management for all Radeon GPUs since r600. Remarco: disabled by default due to stability concerns. En la nueva documentación relativa al tema: http://activedoc.opensuse.org/book/opensuse-reference/chapter-23-power-manag... Termina mandandote a la vieja: 23.5 For More Information # http://www.acpi.info (Advanced Configuration and Power Interface Specification) http://www.lesswatts.org/projects/acpi/ (the ACPI4Linux project at Sourceforge) http://acpi.sourceforge.net/dsdt/index.php (DSDT patches by Bruno Ducrot) http://en.opensuse.org/SDB:Suspend_to_RAM—How to get Suspend to RAM working http://old-en.opensuse.org/Pm-utils—How to modify the general suspend framework Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 24 de noviembre de 2013 09:32, Álvaro Castillo escribió:

El día 24 de noviembre de 2013 10:38, Juan Erbes escribió:

...

El día 24 de noviembre de 2013 07:10, Pinguino Patagonico escribió:

...

Donde configuraste lo relativo al manejo de energía, apagado y suspensión?

Pregunta elemental... --

No he configurado nada puesto que no me ha sido necesario cuando estaba en 12.1 desde el primer kernel hasta el último que disponía en updates. Y es más, acaba de volver a instalar ese kernel 3.7.10-1.16-desktop y funciona correctamente la suspensión en 13.1 http://download.opensuse.org/update/12.3/x86_64/kernel-desktop-3.7.10-1.16.1...

Como decía, debe ser configuración del kernel o algo así, porque por mucho que cambie systemd, si al final cambio de kernel y me funciona será o me da a entender que es el kernel.

...

Lógico, el sistema, "no sabe que hacer", "si no le dices como hacerlo"

http://en.opensuse.org/SDB:Suspend_to_RAM

http://forums.opensuse.org/english/get-technical-help-here/applications/4851...

Si porque... lo he intentado realizar como root como me han dicho arriba y no ha dado resultado con el kernel de 13.1 linux-3.11.6-4 y además ese artículo apunta a 12.3 cuando no tenía ese problema en esa versión.

...

Pero parece que para la 13.1 ha cambiado:

https://news.opensuse.org/2013/11/19/opensuse-13-1-ready-for-action/

a new suspend power state for devices, experimental dynamic power management for all Radeon GPUs since r600 (disabled by default due to stability concerns)

Si, cuando tenía Tumbleweed y 12.1 utilizaba el driver privativo fglrx que supongo que administra la energía en la GPU interna del APU y de la tarjeta externa porque con el driver radeon consumía más la batería. Ahora con el nuevo kernel se puede ahorrar mucha batería con el dpm que activé al añadirlo en la línea del kernel: radeon.dpm=1, pero teniéndolo o no añadido el resultado de la suspensión es la misma.

¿Tendré que usar el kernel viejo siempre supongo?

Primero, deberías ver como activar lo que está desactivado por defecto:

https://news.opensuse.org/2013/11/19/opensuse-13-1-ready-for-action/

a new suspend power state for devices, experimental dynamic power management for all Radeon GPUs since r600 (disabled by default due to stability concerns)

Segundo, seguir la documentación: http://en.opensuse.org/SDB:Suspend_to_RAM—How to get Suspend to RAM working http://old-en.opensuse.org/Pm-utils—How to modify the general suspend framework Basic functionality (or "How it works") The concept is quite easy: the main script (pm-action, called via symlinks as either pm-suspend, pm-hibernate or pm-suspend-hybrid) executes so-called "hooks", executable scripts, in the alphabetical sorted order with the parameter suspend (suspend to RAM) or hibernate (suspend to disk). Once all hooks are done, it puts the machine to sleep. After the machine has woken up again, all those hooks are executed in reverse order with the parameter resume (resume from RAM) or thaw (resume from disk). Note that suspend-hybrid is a placeholder right now, it is not completely implemented. The hooks do various stuff, for example preparing the bootloader, stopping the bluetooth subsystem or unloading of critical modules. Both pm-suspend and pm-hibernate are usually called from HAL, initiated by desktop applets as gnome-power-manager or kpowersave. There is also the possibility to set the machine into high-power and low-power mode, the command pm-powersave is used with an additional parameter of true or false. It works basically the same as the suspend framework. The hooks for suspend are placed in /usr/lib/pm-utils/sleep.d (distribution / package provided hooks) /etc/pm/sleep.d (hooks added by the system administrator) The hooks for the power state are placed in /usr/lib/pm-utils/power.d (distribution / package provided hooks) /etc/pm/power.d (hooks added by the system administrator) Hooks in /etc/pm/ take precedence over those in /usr/lib/pm-utils/, so the system administrator can override the defaults provided by the distribution. Configuration The main configuration file is /usr/lib/pm-utils/defaults. You should not edit this file, since after a package update it might be overwritten with the default settings. Put your config file into /etc/pm/config.d/ instead. You can just put a simple text file with SUSPEND_MODULES="button uhci_hcd" named "modules" or "config" into /etc/pm/config.d and it will override the settings in the system wide configuration file. Variables in config files List of modules to be unloaded before suspend SUSPEND_MODULES="button" # the list of modules to be unloaded before suspend SUSE-specific variables HIBERNATE_METHOD={userspace,kernel} # selects the suspend to disk method. Defaults to userspace. S2RAM_OPTS="" # options that are passed to s2ram. See also s2ram for more information. Troubleshooting If suspend or hibernate did not work correctly, you will probably find some information in the logfile /var/log/pm-suspend.log, for example which hooks were run and what the output of them was. Creating your own hooks If you want to do something specific to your setup during suspend / hibernate, then you can easily put your own hook into /etc/pm/sleep.d. The hooks in this directory will be called in alphabetic order during suspend (that's the reason their names all start with 2 digits, to make the ordering explicit) and in the reverse order during resume. I'm showing a pretty useless demonstration hook here, that will just put some informative lines into your logfile: #!/bin/bash case $1 in hibernate) echo "Hey guy, we are going to suspend to disk!" ;; suspend) echo "Oh, this time we're doing a suspend to RAM. Cool!" ;; thaw) echo "oh, suspend to disk is over, we are resuming..." ;; resume) echo "hey, the suspend to RAM seems to be over..." ;; *) echo "somebody is calling me totally wrong." ;; esac Put this into /etc/pm/sleep.d/66dummy, do a chmod +x /etc/pm/sleep.d/66dummy and it will spew some useless lines during suspend / resume. Warning all the hooks run as user root. This means that you need to be careful when creating temporary files, check that the PATH variable is set correctly etc. to avoid security problems Various tips and tricks / FAQ Triggering suspend manually If you want to trigger suspend manually for debugging, without using HAL and other frameworks, call pm-suspend or pm-hibernate as root. Attention: this is only useful for debugging and it would be good if you knew what you are doing when using this. Using suspend to RAM on machines that are not in the s2ram whitelist If you want to force suspend to RAM, you need to add -f to the S2RAM_OPTS-Variable in a configfile in /etc/pm/config.d/, see Configuration. You also need to put all other options that you need for your machine into this variable. An example might be: S2RAM_OPTS="-f -a 3" It might be a good idea to report your machine on as described in the s2ram-Page, so that you do not need to do this in the future. Disabling a hook If a hook is run which you do not like or which you think is not useful or even harmful, we'd appreciate a bugreport for that. You can however easily disable hooks by just creating an empty file corresponding to the hook in /etc/pm/sleep.d/. Say you want to disable the hook /usr/lib/pm-utils/sleep.d/45pcmcia, you can do this easily by calling touch /etc/pm/sleep.d/45pcmcia Do not set the executable bit on that dummy-hook. (Seems that on openSUSE 11.2 you have to set the execution bit in order to work). Restarting the mouse On some laptops the mouse will hang after an otherwise successful suspend. One way to remedy this is to force a reinit of the PS/2 driver (here i8042) through a hook in /etc/pm/hooks (see hooks) #!/bin/sh echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind --Esox81 20:30, 22 August 2007 (UTC) It seems to not do anything / where is the logfile If it seem to not do anything when called via the desktop applets, then try to call pm-suspend or pm-hibernate manually from a root shell in a terminal. Maybe you'll already get some output that will point you to the problem. The suspend scripts also write a logfile at /var/log/pm-suspend.log. Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org