Problemas con hibernación o gestión de energía?

Hola a todos:

Tengo un “problemilla”, pero la verdad no sé muy bien como explicarlo.

Uso rebornos en un intel nuc10 i7 con DE budgie.

Hace unos días, usando el pc con normalidad, navegando (firefox), de repente, sin hacer nada, inició lo que parecía una hibernación, pero que no daba terminado, como que se alargaba más de 5 minutos, lo cual me parece mucho para un sistema con 32GB de RAM y 65GB de partición swap (sin uso en ese momento). En ese momento, como tardaba, apagué pulsando el botón de encendido +5 segundos.

Al reiniciar, primero no cargaba el kernel normal, como que se quedaba intentando recuperar una imagen de hibernación corrupta, y no pasaba de ahí. Al quedarse atascado, reinicié con el kernel lts sin problemas. Actualicé sistema, por si había algo raro ahí, y al reiniciar (se actualizó kernel), seguía igual.

Reinicié con kernel lts sin problemas de nuevo. Busqué información en internet sobre el problema. Y los síntomas apuntaban efectivamente a una hibernación mal completada, dando como resultado una imagen corrupta irrecuperable. Sigo sin saber porqué se lanzó espontáneamente esa hibernación. Aunque podría haber seguido usando el kernel lts, traté de recuperar el acceso con el kernel normal. Para ello encontré que sin modificar configuraciones de hibernación del sistema, podía hacer un sudo swapoff -a && sudo swapon -a, para restablecer la memoria swap, y eliminar rastro de la imagen de hibernación corrupta. Así logré recuperar el acceso mediante kernel normal, aunque se me queda saliendo un la pantalla de arranque un mensaje de que no es capaz de recuperar la imagen de hibernación de la partición swap, al parecer debido a que sigue detectando una información residual sobre esa imagen corrupta eliminada. No le doy mayor importancia por ahora porque el sistema inicia ya bien tanto con kernel normal como con el lts.

Y así han pasado varios días de uso normal, hasta que hoy se ha repetido el problema pero de una forma algo diferente. Estaba viendo un vídeo en youtube, y de repente la imagen de escritorio se fue, pero por los auriculares seguía oyendo el audio… pantalla apagada, y led de actividad de hd parecido al de la hibernación, pero más irregular…. Al cabo de varios minutos, como seguía sin restablecerse la imagen, el audio seguía sonando, y el sistema no respondía a ctrl+alt+f5 para lanzar otra sesión en consola, ni a un “desesperado” ctrl+alt+del, decidí apagar a la fuerza, con el botón de encendido mantenido 5 seg.

Reinicio, aparentemente no hubo intento de hibernación, aunque no lo descarto, ya que el mensaje de pantalla de arranque dice que no es capaz de recuperar la imagen de hibernación de la swap, pero no dice si es una imagen reciente o una anterior.

No sé si alguno por ahí tiene una idea de qué está pasando y el motivo.

Perdón por el tostón, pero no he sido capaz de resumir más la información de lo sucedido y las dudas que me surgen. De momento parece que tanto el kernel normal (6.16.8.arch3-1) como el lts (6.12.48-1) inician sin problema.

Gracias por adelantado.

Saludos

Could you please share the output of

inxi -G

now, and

journalctl -b -1

later right after rebooting after that problem reoccurs?

¿Podría compartir el resultado de

inxi -G 

ahora, y

journalctl -b -1

más tarde, justo después de reiniciar después de que vuelva a ocurrir ese problema?

Hola:

Pego el resultado de inxi:

$ inxi -G
Graphics:
Device-1: Intel Comet Lake UHD Graphics driver: i915 v: kernel
Display: x11 server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8 driver:
X: loaded: intel unloaded: modesetting dri: i965 gpu: i915 resolution: N/A
API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.2.3-arch1.2
renderer: Mesa Intel UHD Graphics (CML GT2)
API: Vulkan Message: No Vulkan data available.
Info: Tools: api: eglinfo, glxinfo, vulkaninfo x11: xprop,xrandr

El otro comando me lo apunto para cuando me vuelva a dar problemas.

Gracias

envío salida de journalctl -b -1, esta última vez el sistema hizo crash al intentar abrir el centro de control de budgie…

sep 26 23:49:45 pcname kernel: Linux version 6.16.8-arch3-1 (linux@archlinux) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 SMP PREEMPT_DYNA>

sep 26 23:49:45 pcname kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=09681339-8092-47a1-9a50-11d9c69dfecc rw quiet resume=UUID=fc6a037a-8e>

sep 26 23:49:45 pcname kernel: x86/CPU: Running old microcode

sep 26 23:49:45 pcname kernel: BIOS-provided physical RAM map:

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x0000000000100000-0x000000006bc8dfff] usable

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006bc8e000-0x000000006f051fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006f052000-0x000000006f0d1fff] ACPI data

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006f0d2000-0x000000006f1abfff] ACPI NVS

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006f1ac000-0x000000006fba2fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006fba3000-0x000000006fc4dfff] type 20

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006fc4e000-0x000000006fc4efff] usable

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x000000006fc4f000-0x000000007cffffff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved

sep 26 23:49:45 pcname kernel: BIOS-e820: [mem 0x0000000100000000-0x0000000880ffffff] usable

sep 26 23:49:45 pcname kernel: NX (Execute Disable) protection: active

sep 26 23:49:45 pcname kernel: APIC: Static calls initialized

sep 26 23:49:45 pcname kernel: efi: EFI v2.7 by American Megatrends

sep 26 23:49:45 pcname kernel: efi: ACPI=0x6f111000 ACPI 2.0=0x6f111014 TPMFinalLog=0x6f119000 SMBIOS=0x6f9df000 SMBIOS 3.0=0x6f9de000 MEMATTR=0x66047018 E>

sep 26 23:49:45 pcname kernel: efi: Remove mem240: MMIO range=[0xe0000000-0xefffffff] (256MB) from e820 map

sep 26 23:49:45 pcname kernel: e820: remove [mem 0xe0000000-0xefffffff] reserved

sep 26 23:49:45 pcname kernel: efi: Not removing mem241: MMIO range=[0xfe000000-0xfe010fff] (68KB) from e820 map

sep 26 23:49:45 pcname kernel: efi: Not removing mem242: MMIO range=[0xfec00000-0xfec00fff] (4KB) from e820 map

sep 26 23:49:45 pcname kernel: efi: Not removing mem243: MMIO range=[0xfed00000-0xfed03fff] (16KB) from e820 map

sep 26 23:49:45 pcname kernel: efi: Not removing mem244: MMIO range=[0xfee00000-0xfee00fff] (4KB) from e820 map

sep 26 23:49:45 pcname kernel: efi: Remove mem245: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map

sep 26 23:49:45 pcname kernel: e820: remove [mem 0xff000000-0xffffffff] reserved

sep 26 23:49:45 pcname kernel: SMBIOS 3.3.0 present.

sep 26 23:49:45 pcname kernel: DMI: Intel(R) Client Systems NUC10i7FNH/NUC10i7FNB, BIOS FNCML357.0046.2020.0928.1457 09/28/2020

sep 26 23:49:45 pcname kernel: DMI: Memory slots populated: 2/2

sep 26 23:49:45 pcname kernel: tsc: Detected 1600.000 MHz processor

sep 26 23:49:45 pcname kernel: tsc: Detected 1599.960 MHz TSC

sep 26 23:49:45 pcname kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

sep 26 23:49:45 pcname kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

sep 26 23:49:45 pcname kernel: last_pfn = 0x881000 max_arch_pfn = 0x400000000

sep 26 23:49:45 pcname kernel: MTRR map: 5 entries (3 fixed + 2 variable; max 23), built from 10 variable MTRRs

sep 26 23:49:45 pcname kernel: x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT

sep 26 23:49:45 pcname kernel: last_pfn = 0x6fc4f max_arch_pfn = 0x400000000

sep 26 23:49:45 pcname kernel: esrt: Reserving ESRT space from 0x0000000067f26c98 to 0x0000000067f26cd0.

sep 26 23:49:45 pcname kernel: e820: update [mem 0x67f26000-0x67f26fff] usable ==> reserved

sep 26 23:49:45 pcname kernel: Using GB pages for direct mapping

sep 26 23:49:45 pcname kernel: Secure boot disabled

sep 26 23:49:45 pcname kernel: RAMDISK: [mem 0x36e57000-0x37722fff]

sep 26 23:49:45 pcname kernel: ACPI: Early table checksum verification disabled

sep 26 23:49:45 pcname kernel: ACPI: RSDP 0x000000006F111014 000024 (v02 INTEL )

sep 26 23:49:45 pcname kernel: ACPI: XSDT 0x000000006F110728 0000CC (v01 INTEL NUC9i5FN 0000002E AMI 01000013)

sep 26 23:49:45 pcname kernel: ACPI: FACP 0x000000006F0CC000 000114 (v06 INTEL NUC9i5FN 0000002E AMI 00010013)

sep 26 23:49:45 pcname kernel: ACPI: DSDT 0x000000006F089000 042C48 (v02 INTEL NUC9i5FN 0000002E INTL 20160527)

sep 26 23:49:45 pcname kernel: ACPI: FACS 0x000000006F1AB000 000040

añadir que cuando el sistema pierde la visualización, es accesible en remoto con ssh. lo habilité mientras no fallaba para poder apagarlo limpio desde remoto

he aprovechado también para hacer una actualización de todo con $sudo pacman -Syyu

estoy despistadísimo, me da que hay algo que con alguna actualización se le ha aflojado un tornillo, algo relacionado con el entorno gráfico, no sé si tiene que ver con los desarrollos de la v10.10 o la migración a wayland o qué

si estoy en lo cierto, el título del hilo dejaría de ser correcto, pero no sé cómo modificarlo

Are you really running Budgie 10.10 now? I wouldn’t jump to such conclusion or speculation just yet. I suspect you’re hibernation is the primary problem S4. It might be best to completely delete the hibernation file and turn it off, run without hibernation. Hibernation is normally run with a laptop and not necessarily with a desktop system. I use Budgie DE on three systems, and generally only use the Sleep function, and with the lowest power state S5 and make sure in the system BIOS it’s able to use S5. I tend to just use Sleep from the Budgie Power button menu. I’ve also encountered something similar with hibernation which you described. I remedied it by not using it, but I too had some frustrations with it, so I no longer use it.

Hibernation (S4) is very disk intensive and while it is reliable to save the state of the system, I would generally not trust it especially with sensitive data, normally saving your work instead of having the entire session saved from memory to disk. If you have hardware problems, then I almost certainly wouldn’t want to use S4.

Have you checked/updated the system BIOS? If not, it might be a good idea to check the version and at least see if there’s a newer version for your system. If I am not mistaken, I believe Asus has taken over the BIOS support for Intel NUC products.

I see your BIOS might be a bit old (at least around 4 years).

`Intel(R) Client Systems NUC10i7FNH/NUC10i7FNB, BIOS FNCML357.0046.2020.0928.1457 09/28/2020`

Not sure if you’ve allocated more than 32GB of swap, it’s not necessarily recommended to go over the system RAM for swap, it could negatively affect system performance too.

I did some searching and found some (hopefully useful) information regarding swap/hibernation. These are general guidelines so, YMMV.

❌ Why Is It Not Recommended to Use More Swap Than RAM?
1. Misuse Encouragement
Large swap partitions can mask memory problems.
Users might think “I have 65GB swap, so I can run 50 memory-heavy apps” — but in reality, the system will become unusably slow when it starts swapping heavily.
2. Performance Degradation
The OS may start swapping out less-used pages too early if swap is abundant.
This can reduce performance even when you still have free RAM, because swapping has overhead.
3. Hibernation Doesn’t Need More Than RAM
Hibernation requires at least as much swap as RAM (to store RAM contents).
More than that is unnecessary for hibernation.
Example: 32GB RAM → 32GB swap is sufficient for S4 hibernation.
4. Modern Systems Rarely Need Huge Swap
With 32GB RAM, most workloads (even video editing, VMs, development) won’t come close to filling RAM.
Swap is meant for temporary overflow, not permanent memory extension.
✅ Recommended Swap Size for Your Setup
Use Case	Recommended Swap
Hibernation + 32GB RAM	32GB (exact match)
Balanced (hibernation + some overcommit)	32GB–40GB
Minimal (no hibernation, just safety)	4–8GB or a swap file
💡 Best Practice: Use 32GB swap (or slightly more, e.g. 34GB for alignment) if you want hibernation. No need for 65GB.

✅ Better Alternatives
Use a swap file instead of partition (more flexible, easier to resize).
Enable zram (compressed RAM-based swap) for faster performance on modern systems.
# Example: Enable zram with systemd (Arch Linux)
sudo systemctl enable --now systemd-zram-setup@zram0

Use 32GB swap partition/file + zram for best balance of hibernation support and performance.
🔚 Summary
65GB swap is safe but wasteful and not recommended.
It won’t break anything, but encourages poor memory usage and offers no benefit.
For hibernation with 32GB RAM, 32GB swap is sufficient.
Prefer zram + moderate swap for better responsiveness.
Avoid oversized swap unless you’re running memory-intensive scientific workloads or databases (and even then, tuning matters more than size).

Hola Hi-Phile,

Actualmente tengo instalado Budgie 10.9.3, la 10.10 no está liberada aún y va con retraso hasta donde yo sé… Lo que quería decir, es que igual algún paquete va avanzando y liberado antes del lanzamiento oficial de 10.10 y que ello pueda suponer para mi equipo en concreto algún problemilla, pero es una suposición, no lo puedo asegurar.

En cuanto a la posibilidad de fallo por hibernación, después de las últimas pruebas lo descarto ya que, al menos las siguientes veces que me ha vuelto a pasar lo de írseme a negro la pantalla el sistema siguió funcionando. Concretamente, era accesible desde otro pc en la misma lan mediante consola ssh, y además una vez que me pillo haciendo copia de seguridad a un disco externo conectado por usb, ésta no se interrumpió… Esto me inclina a pensar más en un problema relacionado con alguna gestión del entorno gráfico o alguna configuración del kernel relacionada con esto.

De momento no he podido averiguar mucho más. Sigo investigando, pero cualquier ayuda o sugerencia, como la tuya ahora, será bienvenida y agradecida.

1 Like

Gracias, no había pensado en esto de la BIOS/UEFI. Lo revisaré.

1 Like

Ya, tengo 60GB de swap para 32GB de RAM…. reminiscencias de viejos hábitos del pasado :sweat_smile: No lo planifiqué muy bien… Como tenía pensado virtualizar alguna máquina más, pensé que podría serme útil… en la práctica debe ser la parte de disco menos usada!!! Seguramente si tuviera que hacerla de nuevo no reservaría tanta swap… en la línea que indica tu texto de referencia…

Por cierto, parece obtenido con alguna IA ¿podrías indicar cuál usaste si fue el caso para generar ese resumen?

Gracias

Yes,

I exclusively use Brave browser and I like their AI search since it appears to be allowing interactions and the ability to ask further questions. You should check the sources to the answers, and Brave shows the reference pages that it has found in the search from different sources.

Kind regards!

I suspect that the screen going black is related to the power save options. You might want to check the Power settings in Budgie Control Center. Are you blanking the screen after a set time? But, normally after the screen goes blank, it’s supposed to wake up upon key-press or mouse movement, but if not, then yes it could be video related. For example, your display turns off after a set time before the screen blanks? I know this can likely happen when plugged into a TV and not a display monitor. You might want to test it.

Here’s my setting in Budgie DE. I don’t like to turn off my display after a certain time, only when I put into sleep is when I want the display off.

Ya me parecía, :wink: Mi experiencia con ése va en esa línea… pero bueno, esto daría para un hilo aparte fuera de éste. Gracias por el feedback

Yo lo tengo como tú… Aparte de esas opciones, a mí me salen en esa ventana más opciones, como el estado de carga de mi ratón inalámbrico y una elección de configuraciones, que tengo en “equilibrada” o “balanceada”…

En mi caso uso monitor, no TV, así que por ahí no creo que venga el problema.

Hola de nuevo:

Me paso por aquí solamente para contar como quedó el tema “finalmente”. Entrecomillo finalmente porque nunca se sabe :sweat_smile:

Como decía, finalmente parece que es un tema exclusivamente hardware. Los errores estaban viniendo de un problema en el funcionamiento de un chip que gestiona la conversión de la señal de video que sale del i915 (internamente Display Port) hacia el puerto HDMI 2.0a. Este chip se llama lspcon, y haciendo un $journalctl -b | grep -i lspcon se muestran los errores de inicialización de ese chip y en la comunicación con el kernel.

Con el kernel actualizado, tanto el normal, como el LTS, la BIOS actualizada y el firmware del chip lspcon actualizado (lo cual requiere correr Windows externamente, pero con conexión a la misma placa base), el ordenador seguía fallando arbitrariamente: en ejecución, en arranque POST, al reiniciar, conectado a distintos monitores, a la tele, incluso desde dentro del propio menú de BIOS (y por tanto sin correr Linux)… Hice todas las combinaciones con lo que tenía a mano. Al final siempre acababa dando error el lspcon y perdiendo la señal de vídeo, quedando el equipo únicamente accesible en remoto (en mi caso por ssh, como ya comenté en alguna entrada anterior). Al menos así me permitía hacer un apagado limpio, acceder con la aplicación de filemanager del equipo remoto a mis archivos en local, o editar archivos de configuración de grub e initramfs para hacer pruebas y reconfiguraciones.

Ya que lo comento, las distintas opciones que encontré en internet que podían ayudar al kernel a manejar estos errores mejor no resultaron de ayuda. Los parámetros de kernel pasados desde grub, ni las opciones de initramfs sirvieron de nada. Los errores se seguían produciendo y el problema de pérdida de señal de vídeo también.

No encontré que fuera un problema de gestión de energía por el kernel, ni nada que tuviera relación con ningún entorno de escritorio o actualización de aplicaciones, Windows Manager, Display Manager ni nada relacionado con software.

Me quedo con que el chip lspcon se dañó físicamente, por algún motivo que no termino de tener claro, porque tanto pudo ser por una manipulación reciente que hice en la placa (sustitución del fan de CPU), como por “desgaste físico” del circuito por carga de trabajo durante años, o quizás algún leve “recalentón”, que no afectó a nada más, solamente a ese chip. Recalentón que por otra parte no superó nunca los umbrales de funcionamiento limitados en BIOS.

La solución que he encontrado, al menos por ahora, ha sido condenar el puerto HDMI. Dejar de usarlo. En su lugar, compré un dock usb C con salida HDMI, y conectarlo a un puerto thunderbolt que tiene mi NUC. Lo mismo que conectaba al puerto HDMI antes, ahora va conectado al dock y tras 10-15 días de uso no hay problemas.

Si hago los journalctl los errores lspcon siguen saliendo, pero ahora no afectan porque solamente afectan al puerto HDMI del NUC donde ahora no hay conectado nada.

Para mayor precisión, decir que a ese puerto HDMI antes conectaba un monitor VGA a través de un adaptador HDMI-VGA, que funciona tanto con alimentación por HDMI como con alimentación por USB externa, no influyendo esto en los errores de pérdida de video. Ahora va al puerto HDMI del dock sin alimentación externa y no da fallo, y me permite trabajar a la máxima resolución y máxima frecuencia que admite el monitor, como en todos estos años anteriores (1280x1024 @75Hz, casi fullHD).

Me quedó por probar una versión de kernel en pruebas que hay por ahí, un kernel drm-tlp, pero no tenía ánimo de hacer ese experimento. Me conformaré con probar cuando salga la 6.18, si encuentro las ganas o ya se me pasó el queme de estas semanas.

Perdón por el tostón, pero ya que pasé este tormento durante más de un mes, pienso que esta humilde aportación pueda servir a otros que quizás en algún momento tengan el mismo problema. No todo se resuelve por software. Si falla el hardware hay que asumirlo y hacer los cambios necesarios.

Gracias y saludos

P.S.: si fuera posible, creo que sería más correcto cambiar el asunto al hilo para evitar confusiones en búsquedas.

Gracias por avisarnos. Parece ser un asunto complicado, y jamás habría adivinado la solución :sweat_smile:

Thank you for letting us know. It seems to be a tricky issue indeed and I would have never guessed the solution :sweat_smile: