Conversación

Eso suele pasar por un problema al reanudar desde suspensión (suspend/resume), bastante común en algunos Lenovo IdeaPad con Ubuntu. El hecho de que el touchpad funcione pero el teclado no es una pista útil: el sistema vuelve, pero el driver del teclado interno no se re-inicializa correctamente.

Primero intentaría identificar si es solo el teclado interno:

1. Abrí una terminal.

2. Ejecutá:

cat /proc/bus/input/devices | grep -A5 -B2 Keyboard

3. Suspendé cerrando la tapa.

4. Al volver, si podés usar un teclado USB externo, ejecutá el mismo comando y compará.

También podés ver si el kernel reporta errores al reanudar:

journalctl -b | grep -iE "resume|suspend|i8042|atkbd|keyboard"

y específicamente después de reproducir el problema:

sudo dmesg | grep -iE "atkbd|i8042"

Un workaround frecuente para IdeaPad es agregar parámetros al kernel relacionados con el controlador PS/2:

i8042.reset

o

i8042.nomux

o

i8042.reset i8042.nomux

Se prueban agregándolos temporalmente en GRUB al arrancar (tecla e sobre la entrada de Ubuntu) y, si funcionan, se hacen permanentes.

Antes de tocar eso, me ayudaría saber:

• ¿Qué modelo exacto de IdeaPad es?
• ¿Qué versión de Ubuntu (`lsb_release -a`)?
• ¿Pasa al cerrar la tapa únicamente, o también si hacés `systemctl suspend` desde una terminal?

Con esos datos puedo apuntar mejor al driver específico.

Si también pasa con systemctl suspend, entonces no parece estar relacionado con el sensor de la tapa sino con la reanudación desde suspensión en sí.

Probemos a identificar qué driver maneja el teclado:

sudo libinput list-devices | grep -A20 -i keyboard

o:

cat /proc/bus/input/devices

Buscá algo como:

• `AT Translated Set 2 keyboard` → suele usar `atkbd/i8042`
• `Lenovo Extra Buttons`
• algún dispositivo HID (`hid_multitouch`, `hid_generic`, etc.)

Mientras tanto, hay tres cosas que probaría porque son las causas más frecuentes:

1. Ver si hay errores del teclado al reanudar

Después de volver de suspensión (aunque el teclado no funcione), usando una terminal abierta o un teclado USB:

journalctl -b -g atkbd

y

journalctl -b -g i8042

2. Probar parámetros del kernel

Editá /etc/default/grub:

sudo nano /etc/default/grub

Buscá:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

y probá primero:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset"

Luego:

sudo update-grub
sudo reboot

Si no cambia nada, probaría:

i8042.nomux

o ambos:

i8042.reset i8042.nomux

3. Ver si el problema es específico del modo de suspensión

Ubuntu 24.04 puede usar s2idle en vez de suspensión profunda (deep) en algunos Lenovo.

Mostrame qué devuelve:

cat /sys/power/mem_sleep

Si aparece algo como:

[s2idle] deep

o

s2idle [deep]

es información muy útil porque varios IdeaPad tienen problemas de teclado al volver desde s2idle y se arreglan forzando deep.

Pasame:

• la salida de `cat /sys/power/mem_sleep`
• el modelo exacto (`sudo dmidecode -s system-product-name`)

y te digo cuál de las soluciones tiene más chances para tu equipo.

Interesante. Si cat /sys/power/mem_sleep muestra:

s2idle [deep]

entonces ya estás usando **deep**, que normalmente es la solución para muchos Lenovo. Eso descarta una de las causas más comunes.

El modelo **83KA** corresponde a una familia relativamente nueva de IdeaPad, y hay varios reportes de problemas de reanudación con el controlador PS/2 (i8042/atkbd) en kernels 6.x.

Lo siguiente que probaría, en este orden:

1. Ver si el teclado vuelve recargando el driver

Cuando el teclado quede muerto tras un suspend, conectá un teclado USB y ejecutá:

sudo modprobe -r atkbd
sudo modprobe atkbd

Si vuelve a funcionar, ya tenemos identificado al culpable.

Si atkbd no se puede descargar porque está en uso:

sudo modprobe -r psmouse atkbd
sudo modprobe atkbd
sudo modprobe psmouse

2. Probar `i8042.reset`

Agregá al kernel:

i8042.reset

en /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset"

Luego:

sudo update-grub
sudo reboot

3. Si no alcanza, probar también `i8042.nomux`

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset i8042.nomux"

y reiniciar.

4. Revisar si ya está corregido en un kernel más nuevo

Ubuntu 24.04 suele venir con kernel 6.8, pero muchas correcciones para Lenovo entraron en 6.11, 6.12 y posteriores.

Mostrame:

uname -r

Si estás en 6.8.x, probablemente valga la pena probar el kernel HWE más nuevo que tenga disponible Ubuntu actualmente.

Lo que más me interesa ahora es saber:

uname -r

y si el teclado revive o no con:

sudo modprobe -r atkbd
sudo modprobe atkbd

porque eso nos dirá si estamos frente a un bug clásico de atkbd/i8042 o a algo más específico del firmware Lenovo.

Yo no saltaría a **Ubuntu 26.04** (además, hoy no existe una versión estable 26.04 LTS; la próxima LTS después de 24.04 es 26.04, pero aún no está disponible como versión final).

Antes probaría cosas de mucho menor costo:

1. **Actualizar completamente 24.04**

   sudo apt update
   sudo apt full-upgrade

y reiniciar.

2. Ver qué kernel tenés:

   uname -r

3. Probar los parámetros:

   i8042.reset

y si no alcanza:

   i8042.reset i8042.nomux

Si estás en un kernel 6.8.x, hay bastantes chances de que el problema ya esté corregido en kernels más recientes sin necesidad de cambiar de distribución.

Pasame la salida de:

uname -r

y te digo si conviene intentar subir solamente el kernel o si realmente vale la pena pensar en una actualización mayor.

¿Seguro que fue:

uname -r

y te devolvió **6.17.0**?

Porque Ubuntu 24.04 no trae un kernel 6.17 estable por defecto, así que si ese dato es correcto ya estás en un kernel bastante reciente. En ese caso, actualizar la distro probablemente **no arregle** este problema, porque ya estarías usando un kernel más nuevo que el de Ubuntu 24.04 estándar.

Con ese dato, mis sospechas se concentran en:

• un bug específico del firmware Lenovo IdeaPad 83KA;
• el controlador `atkbd/i8042`;
• o una interacción ACPI al reanudar.

Lo siguiente que haría es verificar si efectivamente el teclado interno desaparece del sistema después del resume:

grep -A4 -B1 -i keyboard /proc/bus/input/devices

antes y después de suspender.

Y la prueba más valiosa:

sudo modprobe -r atkbd
sudo modprobe atkbd

justo después de volver de suspensión (usando un teclado USB si hace falta).

Si con eso revive el teclado, ya sabemos que el problema es el driver y podemos automatizar el reinicio del módulo al reanudar.

Si no revive, entonces me interesa ver los logs:

journalctl -b | grep -iE 'atkbd|i8042|keyboard|acpi'

Idealmente después de reproducir el fallo.

Por ahora, con un kernel tan nuevo, yo no invertiría tiempo en reinstalar o actualizar Ubuntu. El problema parece más específico que eso.

Ese mensaje es muy revelador:

atkbd serio0: Failed to deactivate keyboard on isa0060/serio0

Significa que durante la transición de suspensión o reanudación el driver atkbd intenta enviar comandos al controlador PS/2 del teclado interno y el hardware/firmware no responde como espera. No parece que el teclado desaparezca del sistema; parece que queda en un estado inconsistente del que el driver no logra recuperarlo.

Como ya verificaste que:

• pasa con `systemctl suspend`;
• estás usando `deep`;
• recargar `atkbd` no lo revive;
• estás en un kernel muy reciente;

yo probaría estas opciones del kernel, porque justamente afectan la inicialización del controlador PS/2:

1. Primero:

   i8042.reset

2. Si no cambia nada:

   i8042.nomux

3. Luego:

   i8042.reset i8042.nomux

4. Y si sigue igual:

   i8042.dumbkbd

(menos elegante, pero a veces evita ciertos intercambios de comandos que fallan al reanudar).

También me interesa saber si aparecen mensajes similares alrededor de ese error. Por ejemplo:

journalctl -b | grep -A5 -B5 "Failed to deactivate keyboard"

o

dmesg | grep -A10 -B10 atkbd

Busco cosas como:

• `probe failed`
• `timeout`
• `controller selftest failed`
• `i8042: ...`
• errores ACPI inmediatamente antes o después

Porque el mensaje que encontraste apunta bastante más a un problema de firmware/PS2 que a GNOME, systemd o Ubuntu en general.

Si me pegás unas 15-20 líneas alrededor de ese error, probablemente podamos identificar cuál de los parámetros i8042.* tiene más sentido probar primero.

Sí, definitivamente lo probaría.

Antes habías escrito algo como "soli [s2idle]" y yo interpreté mal la salida. Si en realidad tenés:

[s2idle] deep

entonces el sistema está usando **s2idle**, no deep.

Muchos Lenovo IdeaPad tienen justamente problemas de resume con s2idle, incluyendo dispositivos que no vuelven a inicializarse correctamente.

Probá qué opciones tenés:

cat /sys/power/mem_sleep

Si ves:

[s2idle] deep

forzá deep agregando al kernel:

mem_sleep_default=deep

en /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

Luego:

sudo update-grub
sudo reboot

Y verificá:

cat /sys/power/mem_sleep

Debería mostrar:

s2idle [deep]

Si el problema desaparece, ya encontraste la causa.

Incluso si no lo resuelve completamente, la combinación que yo probaría para ese error de atkbd sería:

mem_sleep_default=deep i8042.reset

porque ataca las dos causas más probables: el método de suspensión y la reinicialización del controlador PS/2.

Por lo que contás (Failed to deactivate keyboard on isa0060/serio0), mi apuesta sería primero a **pasar de s2idle a deep** antes que a cualquier otra cosa. Es el cambio con mejor relación esfuerzo/probabilidad de éxito.

Eso es un dato muy interesante.

Si ahora:

cat /sys/power/mem_sleep

muestra solamente:

s2idle

sin [ ] y sin deep, significa que **el kernel no tiene disponible el modo deep en este arranque**. No es que esté usando s2idle por elección: es la única opción que expone.

Eso suele pasar por alguna de estas razones:

1. El firmware/BIOS no anuncia soporte para S3 ("deep sleep").

2. Algún parámetro del kernel deshabilitó S3.

3. Una actualización de BIOS o kernel cambió la detección de estados de suspensión.

Me gustaría ver:

cat /sys/power/mem_sleep

(la salida exacta)

y también:

dmesg | grep -i "ACPI.*sleep"

o

dmesg | grep -i "Low-power S0"

o

dmesg | grep -i "suspend"

porque normalmente el kernel deja mensajes del estilo:

ACPI: PM: (supports S0 S4 S5)

o

Low-power S0 idle used by default for system suspend

Si tu IdeaPad sólo expone S0ix/s2idle al sistema operativo, entonces mem_sleep_default=deep no puede hacer nada porque no existe un modo deep para seleccionar.

Por cierto, que ahora aparezca sólo s2idle me hace sospechar que quizá antes leíste la salida de otra forma o que cambió algo entre reinicios. En cualquier caso, si el BIOS sólo ofrece s2idle, el camino pasa más por entender el error de atkbd que por forzar deep.

¿Podés pegar la salida completa de?

cat /sys/power/mem_sleep

y de:

dmesg | grep -iE 'ACPI|S0|S3|sleep'

(no hace falta todo el log, unas líneas relevantes alcanzan). Eso debería decirnos si el equipo realmente soporta S3/deep o no.

Eso es un dato muy interesante.

Si ahora:

cat /sys/power/mem_sleep

muestra solamente:

s2idle

sin [ ] y sin deep, significa que **el kernel no tiene disponible el modo deep en este arranque**. No es que esté usando s2idle por elección: es la única opción que expone.

Eso suele pasar por alguna de estas razones:

1. El firmware/BIOS no anuncia soporte para S3 ("deep sleep").

2. Algún parámetro del kernel deshabilitó S3.

3. Una actualización de BIOS o kernel cambió la detección de estados de suspensión.

Me gustaría ver:

cat /sys/power/mem_sleep

(la salida exacta)

y también:

dmesg | grep -i "ACPI.*sleep"

o

dmesg | grep -i "Low-power S0"

o

dmesg | grep -i "suspend"

porque normalmente el kernel deja mensajes del estilo:

ACPI: PM: (supports S0 S4 S5)

o

Low-power S0 idle used by default for system suspend

Si tu IdeaPad sólo expone S0ix/s2idle al sistema operativo, entonces mem_sleep_default=deep no puede hacer nada porque no existe un modo deep para seleccionar.

Por cierto, que ahora aparezca sólo s2idle me hace sospechar que quizá antes leíste la salida de otra forma o que cambió algo entre reinicios. En cualquier caso, si el BIOS sólo ofrece s2idle, el camino pasa más por entender el error de atkbd que por forzar deep.

¿Podés pegar la salida completa de?

cat /sys/power/mem_sleep

y de:

dmesg | grep -iE 'ACPI|S0|S3|sleep'

(no hace falta todo el log, unas líneas relevantes alcanzan). Eso debería decirnos si el equipo realmente soporta S3/deep o no.

La foto ayuda bastante.

Lo más importante es esta línea:

ACPI: PM: (supports S0 S4 S5)

Si el firmware anunciara suspensión profunda clásica (S3), normalmente verías algo como:

supports S0 S3 S4 S5

o similar.

Que aparezca **S0 S4 S5** y no **S3** explica por qué ahora mem_sleep sólo muestra s2idle: tu BIOS/firmware no está exponiendo S3 al sistema operativo. En otras palabras, **no hay modo deep disponible** para Linux, así que mem_sleep_default=deep no puede hacer nada.

Además, veo otro mensaje interesante después del resume:

ucsi_acpi ... failed to re-enable notifications (-110)

Eso es un timeout del controlador USB-C/UCSI al volver de suspensión. No prueba que sea la causa del teclado, pero sí indica que el resume no está siendo completamente limpio y que hay varios dispositivos que vuelven con problemas.

A esta altura, yo me enfocaría en el controlador PS/2:

1. Probá arrancar con:

   i8042.reset

2. Si sigue igual:

   i8042.nomux

3. Luego:

   i8042.reset i8042.nomux

4. Y si nada cambia:

   i8042.dumbkbd

Además, me gustaría ver unas líneas alrededor del error original. En vez de filtrar por ACPI, probá:

journalctl -b | grep -A5 -B5 "Failed to deactivate keyboard"

o:

dmesg | grep -A10 -B10 atkbd

Lo que intento averiguar es si aparece algo como:

atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
i8042: ...
timeout ...

o si hay otros errores inmediatamente antes.

Con lo que mostraste, ya podemos descartar bastante fuerte la hipótesis de "usar deep". El firmware de esa máquina parece ser de los que sólo ofrecen **Modern Standby (S0ix/s2idle)**, así que la investigación pasa por el bug de atkbd/i8042 o por una regresión específica de Lenovo.

Sí, definitivamente lo probaría.

Antes habías escrito algo como "soli [s2idle]" y yo interpreté mal la salida. Si en realidad tenés:

[s2idle] deep

entonces el sistema está usando **s2idle**, no deep.

Muchos Lenovo IdeaPad tienen justamente problemas de resume con s2idle, incluyendo dispositivos que no vuelven a inicializarse correctamente.

Probá qué opciones tenés:

cat /sys/power/mem_sleep

Si ves:

[s2idle] deep

forzá deep agregando al kernel:

mem_sleep_default=deep

en /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

Luego:

sudo update-grub
sudo reboot

Y verificá:

cat /sys/power/mem_sleep

Debería mostrar:

s2idle [deep]

Si el problema desaparece, ya encontraste la causa.

Incluso si no lo resuelve completamente, la combinación que yo probaría para ese error de atkbd sería:

mem_sleep_default=deep i8042.reset

porque ataca las dos causas más probables: el método de suspensión y la reinicialización del controlador PS/2.

Por lo que contás (Failed to deactivate keyboard on isa0060/serio0), mi apuesta sería primero a **pasar de s2idle a deep** antes que a cualquier otra cosa. Es el cambio con mejor relación esfuerzo/probabilidad de éxito.

Ese mensaje es muy revelador:

atkbd serio0: Failed to deactivate keyboard on isa0060/serio0

Significa que durante la transición de suspensión o reanudación el driver atkbd intenta enviar comandos al controlador PS/2 del teclado interno y el hardware/firmware no responde como espera. No parece que el teclado desaparezca del sistema; parece que queda en un estado inconsistente del que el driver no logra recuperarlo.

Como ya verificaste que:

• pasa con `systemctl suspend`;
• estás usando `deep`;
• recargar `atkbd` no lo revive;
• estás en un kernel muy reciente;

yo probaría estas opciones del kernel, porque justamente afectan la inicialización del controlador PS/2:

1. Primero:

   i8042.reset

2. Si no cambia nada:

   i8042.nomux

3. Luego:

   i8042.reset i8042.nomux

4. Y si sigue igual:

   i8042.dumbkbd

(menos elegante, pero a veces evita ciertos intercambios de comandos que fallan al reanudar).

También me interesa saber si aparecen mensajes similares alrededor de ese error. Por ejemplo:

journalctl -b | grep -A5 -B5 "Failed to deactivate keyboard"

o

dmesg | grep -A10 -B10 atkbd

Busco cosas como:

• `probe failed`
• `timeout`
• `controller selftest failed`
• `i8042: ...`
• errores ACPI inmediatamente antes o después

Porque el mensaje que encontraste apunta bastante más a un problema de firmware/PS2 que a GNOME, systemd o Ubuntu en general.

Si me pegás unas 15-20 líneas alrededor de ese error, probablemente podamos identificar cuál de los parámetros i8042.* tiene más sentido probar primero.

Sí, definitivamente lo probaría.

Antes habías escrito algo como "soli [s2idle]" y yo interpreté mal la salida. Si en realidad tenés:

[s2idle] deep

entonces el sistema está usando **s2idle**, no deep.

Muchos Lenovo IdeaPad tienen justamente problemas de resume con s2idle, incluyendo dispositivos que no vuelven a inicializarse correctamente.

Probá qué opciones tenés:

cat /sys/power/mem_sleep

Si ves:

[s2idle] deep

forzá deep agregando al kernel:

mem_sleep_default=deep

en /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

Luego:

sudo update-grub
sudo reboot

Y verificá:

cat /sys/power/mem_sleep

Debería mostrar:

s2idle [deep]

Si el problema desaparece, ya encontraste la causa.

Incluso si no lo resuelve completamente, la combinación que yo probaría para ese error de atkbd sería:

mem_sleep_default=deep i8042.reset

porque ataca las dos causas más probables: el método de suspensión y la reinicialización del controlador PS/2.

Por lo que contás (Failed to deactivate keyboard on isa0060/serio0), mi apuesta sería primero a **pasar de s2idle a deep** antes que a cualquier otra cosa. Es el cambio con mejor relación esfuerzo/probabilidad de éxito.

Eso es un dato muy interesante.

Si ahora:

cat /sys/power/mem_sleep

muestra solamente:

s2idle

sin [ ] y sin deep, significa que **el kernel no tiene disponible el modo deep en este arranque**. No es que esté usando s2idle por elección: es la única opción que expone.

Eso suele pasar por alguna de estas razones:

1. El firmware/BIOS no anuncia soporte para S3 ("deep sleep").

2. Algún parámetro del kernel deshabilitó S3.

3. Una actualización de BIOS o kernel cambió la detección de estados de suspensión.

Me gustaría ver:

cat /sys/power/mem_sleep

(la salida exacta)

y también:

dmesg | grep -i "ACPI.*sleep"

o

dmesg | grep -i "Low-power S0"

o

dmesg | grep -i "suspend"

porque normalmente el kernel deja mensajes del estilo:

ACPI: PM: (supports S0 S4 S5)

o

Low-power S0 idle used by default for system suspend

Si tu IdeaPad sólo expone S0ix/s2idle al sistema operativo, entonces mem_sleep_default=deep no puede hacer nada porque no existe un modo deep para seleccionar.

Por cierto, que ahora aparezca sólo s2idle me hace sospechar que quizá antes leíste la salida de otra forma o que cambió algo entre reinicios. En cualquier caso, si el BIOS sólo ofrece s2idle, el camino pasa más por entender el error de atkbd que por forzar deep.

¿Podés pegar la salida completa de?

cat /sys/power/mem_sleep

y de:

dmesg | grep -iE 'ACPI|S0|S3|sleep'

(no hace falta todo el log, unas líneas relevantes alcanzan). Eso debería decirnos si el equipo realmente soporta S3/deep o no.

La foto ayuda bastante.

Lo más importante es esta línea:

ACPI: PM: (supports S0 S4 S5)

Si el firmware anunciara suspensión profunda clásica (S3), normalmente verías algo como:

supports S0 S3 S4 S5

o similar.

Que aparezca **S0 S4 S5** y no **S3** explica por qué ahora mem_sleep sólo muestra s2idle: tu BIOS/firmware no está exponiendo S3 al sistema operativo. En otras palabras, **no hay modo deep disponible** para Linux, así que mem_sleep_default=deep no puede hacer nada.

Además, veo otro mensaje interesante después del resume:

ucsi_acpi ... failed to re-enable notifications (-110)

Eso es un timeout del controlador USB-C/UCSI al volver de suspensión. No prueba que sea la causa del teclado, pero sí indica que el resume no está siendo completamente limpio y que hay varios dispositivos que vuelven con problemas.

A esta altura, yo me enfocaría en el controlador PS/2:

1. Probá arrancar con:

   i8042.reset

2. Si sigue igual:

   i8042.nomux

3. Luego:

   i8042.reset i8042.nomux

4. Y si nada cambia:

   i8042.dumbkbd

Además, me gustaría ver unas líneas alrededor del error original. En vez de filtrar por ACPI, probá:

journalctl -b | grep -A5 -B5 "Failed to deactivate keyboard"

o:

dmesg | grep -A10 -B10 atkbd

Lo que intento averiguar es si aparece algo como:

atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
i8042: ...
timeout ...

o si hay otros errores inmediatamente antes.

Con lo que mostraste, ya podemos descartar bastante fuerte la hipótesis de "usar deep". El firmware de esa máquina parece ser de los que sólo ofrecen **Modern Standby (S0ix/s2idle)**, así que la investigación pasa por el bug de atkbd/i8042 o por una regresión específica de Lenovo.

Encontré algo bastante prometedor para tu caso.

Tu máquina es:

Lenovo IdeaPad Slim 3 15AHP10 (83KA)
AMD Ryzen
teclado PS/2 (atkbd/i8042)

Y hay varios reportes muy parecidos en IdeaPad Slim recientes:

• Usuarios de IdeaPad Slim 3 AMD reportan que después de suspend el teclado interno muere mientras touchpad y teclados USB siguen funcionando.
• Hay reportes de suspensión + teclado congelado específicamente en IdeaPad Slim 3 con Ryzen.
• Existe incluso un bug abierto de Ubuntu para un **Lenovo IdeaPad Slim 3 15ARP10** (misma familia) donde aparece exactamente el mensaje:

  atkbd serio0: Failed to deactivate keyboard on isa0060/serio0

después del suspend/resume.

Lo más interesante es esto:

Posible workaround con AMD PMC

En un caso de IdeaPad Slim 3 AMD la solución fue:

sudo tee /etc/modprobe.d/amd_pmc.conf <<< 'options amd_pmc enable_stb=1'

Reiniciar y verificar:

cat /sys/module/amd_pmc/parameters/enable_stb

Debe devolver:

Y

La explicación es que modifica cómo AMD maneja el estado de suspensión moderno (S0ix).

Yo probaría eso antes de reinstalar nada.

Otra pista interesante

Encontré un reporte de otro usuario con un **IdeaPad Slim 3 15AHP10**, exactamente tu modelo, que afirma haberlo solucionado con:

i8042.debug=1 i8042.nopnp=1 i8042.noloop

en la línea del kernel.

Vos ya probaste reset, nomux y similares, pero no recuerdo que hayamos probado:

i8042.nopnp=1
i8042.noloop

y ese reporte menciona específicamente tu modelo.

Qué haría yo ahora

1. Probar AMD PMC:

   sudo tee /etc/modprobe.d/amd_pmc.conf <<< 'options amd_pmc enable_stb=1'
   sudo reboot

2. Si sigue igual, probar en GRUB:

   i8042.nopnp=1 i8042.noloop

3. Si sigue igual, probar la combinación:

   i8042.debug=1 i8042.nopnp=1 i8042.noloop

4. Recién después pensaría en cambiar de kernel.

Respecto a "¿me conviene ir a un Ubuntu más nuevo?":

No creo que el salto de distro sea la clave. Ya estás en un kernel muy nuevo. De hecho, varios de los reportes aparecen con kernels 6.10+ y 6.11+, así que no parece algo resuelto simplemente por usar una versión más reciente.

Yo apostaría primero por el workaround de amd_pmc enable_stb=1, porque es el único hallazgo que encontré asociado específicamente a IdeaPad Slim 3 AMD y suspensión moderna.