Saludos:
La semana pasada hice una instalación limpia del Tumbleweed y he notado que al dejar la laptop sin actividad durante un par de horas, al mover el mouse o presionar un una tecla, en vez de que la pantalla se prenda y pueda trabajar otra vez, resulta que el sistema está colgado y no muestra nada (solo pantalla negra) y no me queda más opción que apagar el equipo manteniendo presionado el botón “power”.
Me extraña porque NUNCA me había pasado antes, sobretodo porque tengo desactivadas las opción de “suspensión e hibernación” con: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
Según investigué, podría tratarse de un problema con el driver de video Nvidia, pero no se sabe con certeza, así que recurro al foro para preguntar ¿A alguien más le ha pasado? ¿Algún consejo?
Igual lo he reportado en el foro de Nvidia (aunque tuve que crear cuenta nueva, ya que no me dejaba iniciar sesión con la de siempre, quizás porque llevo años sin acceder).
Sistema operativo: openSUSE Tumbleweed 20250613
Versión de KDE Plasma: 6.3.5
Versión de KDE Frameworks: 6.14.0
Versión de Qt: 6.9.1
Versión del kernel: 6.15.2-1-default (64 bits)
Plataforma gráfica: X11
Procesadores: 24 × 13th Gen Intel® Core™ i7-13700HX
Memoria: 31.1 GiB de RAM
Procesador gráfico: NVIDIA GeForce RTX 4070 Laptop GPU
Fabricante: Acer
Nombre del producto: Predator PH16-71
Versión del sistema: V1.16
De momento lo que hice fue desinstalar el open-driver y colocar el repositorio de Nvidia como principal, (instalando el módulo de kmp (nvidia-driver-G06-kmp-default )
Además, según vi en el foro en Inglés, hay otro que tiene el mismo problema que yo pero en su caso lo detectado fue por el diming (el brillo de la pantalla).
También le di un “zypper up” y desactivé el cambio de brillo de la pantalla (opciones de energía).
De momento, no ha vuelto a ocurrir, pero solo ha pasado un día, tendría que pasar al menos una semana para estar seguro de que ya está solucionado.
EDITO:
Perdona, me di cuenta que no respondí tu pregunta:
Lo que hice además, incluso antes de publicar el post del inicio, fue que para ir descartando, desactivé el bloqueo automático (así nunca me aparece el salvapantallas).
No funcionó, ya que el problema era cuando la pantalla se apaga después de un tiempo determinado (eso está bien) y cuando quiero volver a iniciar, en ocasiones ya la pantalla no prende, se queda “negra” y no responde a nada, dejándome sin más opción que apagar la laptop de forma forzada (con el botón power).
Ojalá que con los nuevos cambios que hice ya esté solucionado, sobre-todo porque antes no me sucedía.
Si deshabilitas la confirmación del apagado, pulsar el botón de apagado debería apagar el equipo normalmente.
[Añado]
En la configuración de la gestión de energía puedes indicar qué hacer al pulsar ese botón. Por defecto lo que debería hacer es mostrarte el menú de salida (la confirmación de apagado).
En tu caso, apagar por la fuerza implica pulsar el botón de apagado y mantenerlo pulsado hasta que se desconecta la corriente. Pero en principio no era necesario. Incluso si estás con la configuración estándar, yo diría que pulsar Intro justo después de pulsar el botón de apagado debería ser suficiente.
Nótese que esto es diferente a apagar pulsando el botón de apagado y manteniéndolo pulsado hasta que se desconecta la corriente.
No tengo problemas con apagar pantalla (leap 15.5) , en 15.6 no lo probé, porque el 2º monitor se bloquea y deja de funcionar (kernel por usar los drives de nouveau .
En otras placas desactivo el ahorro de energía de pcie de la gráfica .Contraseña:
frank:~ # inxi -Gz
Graphics:
Device-1: Intel CoffeeLake-H GT2 [UHD Graphics 630] driver: i915 v: kernel
Device-2: NVIDIA GP107M [GeForce GTX 1050 Mobile] driver: nouveau
v: kernel
Device-3: Quanta HP Wide Vision HD Camera type: USB driver: uvcvideo
Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 driver: X:
loaded: modesetting unloaded: fbdev,vesa dri: iris,zink gpu: i915,nouveau
resolution: 1: 1920x1080 2: 1920x1080~60Hz
API: OpenGL v: 4.6 Mesa 22.3.5 renderer: Mesa Intel UHD Graphics 630 (CFL
GT2)
frank:~ #
No activo cierre de sesión , ya que el pass, es de mas d 19 caracteres .
Hace mucho que las computadoras se apagan por software. Lo he explicado aquí:
Btw precisamente, el apagado por indicación al kernel viene de hecho desactivado. Y bueno, la mayor parte de los sistemas de ficheros se recuperan bastante bien cuando hay cortes de corriente y tal.
Hay un truco que, a veces, funciona en ese caso. Intenta abrir un terminal virtual (Crtl+Alt+F1 o F2) y si aparece la pantalla de login, entonces entras como root, tumbas el Xorg con init 3, lo vuelves a levantas con init 5 y entras en la sesión gráfica con Crtl+Alt+F7 si no te sale Plasma.
Si no funciona, haz lo que indica mi compañero pulsa brevemente el boton de apagado, si no con RESUIB (tienes que activarlo en Yast, creo que no esta por defecto).
Si deshabilitas la confirmación del apagado, pulsar el botón de apagado debería apagar el equipo normalmente.
¿No sería esa mas bien una configuración de la bios? Solo para aclarar, el sistema se cuelga totalmente, es decir, cuando dije pantalla negra, me refiero a que es lo único que muestra el monitor (que ni-siquiera enciende).
Hay un truco que, a veces, funciona en ese caso. Intenta abrir un terminal virtual (Crtl+Alt+F1 o F2) y si aparece la pantalla de login, entonces entras como root, tumbas el Xorg con init 3, lo vuelves a levantas con init 5 y entras en la sesión gráfica con Crtl+Alt+F7 si no te sale Plasma.
Si no funciona, haz lo que indica mi compañero pulsa brevemente el boton de apagado, si no con RESUIB (tienes que activarlo en Yast, creo que no esta por defecto).
Si, intenté también esa combinación (entre otras) pero no mostraba nada la pantalla.
No conocía eso del RESUB, voy a revisarlo,
Gracias
Esto entra en el conjunto de cosas que solo se pueden saber probando. Con frecuencia, si el driver de una gráfica hace que se apague un monitor lo único que sucede es que el monitor está apagado. No hay razón general para pensar otra cosa a menos que se pruebe y efectivamente el sistema esté bloqueado. Los leds (el de teclado etc.) ayudan, pero cada vez es más frecuente no tenerlos
Desde antes de Leap esto ya no se activaba por defecto. No tengo una opinión formada al respecto, hubo un tiempo en que lo activaba manualmente durante la instalación, ahora ya nunca. También es que antes el sistema se comportaba peor si lo apagabas por las bravas.
Si te has fijado, si antaño reiniciabas “a las bravas” o se iba la corriente o algo así, al arrancar el sistema lo primero que hacía era comprobar el estado de los sistemas de ficheros (y ya no todos, no era lo mismo reiserfs que ext2 ni que XFS), y o bien lo interrumpías y te arriesgabas o te tirabas un buen rato esperando.
Al desmontar los sistemas de ficheros con REISUB como los dispositivos se desmontaban correctamente (más o menos), pero con los sistemas de ficheros basados en diarios (journals) esto ya no sucede. Reinicias o arrancas tras el corte de luz, y el sistema de ficheros consulta su registro y monta el sistema apropiadamente para seguir funcionando.
Aun así, el REISUB podría ser útil para asegurarse de que se vuelcan los flujos (streams) de los dispositivos de almacenamiento para poder cerrarlos. Por ejemplo, si tú copias un fichero de un dispositivo a otro y apagas la computadora justo al ver el mensaje de “copia finalizada” probablemente la copia realmente no haya tenido aún lugar. Es a lo que se refieren con “sincronizar los flujos”, buffers y demás (o más sencillo: es la primera parte de lo que hace desmontar umount). La idea es que el REISUB obligue al kernel a sincronizar los flujos y buffers varios antes de reiniciar, algo así como intentar obligar al sistema a desmontar los dispositivos correctamente por la fuerza y por tanto, si algo estaba pendiente de ser escrito en el disco, será escrito.
De lo que pone en ese breve texto, yo entiendo que se refiere a que hacer esto en un sistema moderno puede ser problemático porque digamos que el kernel estará en un estado “imprevisible”. Y por tanto, sí, será la peor de las ideas.
No, COW es otra cosa y puede ser un poco sutil. Por ejemplo, si abres un fichero y lo modificas, la parte modificada se guardará en una nueva ubicación libre. Si copias un fichero en el mismo sistema de ficheros para crear una copia, btrfs creará en su lugar una referencia al original hasta que se modifique uno de los dos.
En cambio, en otros sistemas, si abres un fichero para modificar algo, se tiene que escribir todo el fichero de nuevo al disco.
Lo del post anterior es que la mayoría de sistemas no escriben físicamente en disco inmediatamente y puede haber demoras de p.ej. hasta 5 segundos entre que la operación se hace en los buffers y se hace la escritura en el disco.
Por lo que yo entiendo, en realidad depende de qué variables estén configuradas (valor de sysrq).
De todas formas, R no es evidente que funcione en Wayland, E termina todos los procesos salvo el principal, y I mata todos los procesos que no haya terminado E, salvo el principal. Diría que hay que añadir B de todas formas para reiniciar.
Bueno, ahí la conclusión que sacan es que es mejor utilizar SUB en lugar de REISUB.
En mi honesta opinión, recuerdo cuando fui a un curso de estos de optimización del sistema (system tuning). La primera lección fue: UNIX tiene (en aquel momento) más de 40 años; Linux tiene más de 20 años. (Ahora tiene más de 30). Son sistemas conocidos. Probablemente la mayoría de configuraciones se establezcan de esa forma por alguna razón.
Parece que la forma más segura sea Ctrl+Impr+B por lo que leo. Todo es en base a discusiones en listas de correo y lo que hace cada distro por sí misma.
En lo único que parece que están de acuerdo es en usar sólo B para evitar un sincronizado de un kernel corrupto que pueda dañar los datos.
