¿Cómo puedo depurar un problema de Suspender a RAM en Linux?

15

Espero obtener sugerencias basadas en la experiencia sobre cómo solucionar el problema de la suspensión a RAM. Un consejo específico para mi situación (detallado a continuación) sería excelente, pero también estoy interesado en consejos generales sobre cómo depurar estos problemas.

El problema:

A menudo, cuando intento suspender mi máquina, se atasca en un estado "no suspendido pero no despierto". A menudo, la pantalla estará completamente negra, pero a veces tendrá el siguiente mensaje de error:

GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0)

Además, este estado también estará acompañado por los fanáticos a toda velocidad. La única forma de sacarlo de este estado es apagar manualmente la computadora portátil.

Alguna información

$ uname -a
Linux baltar 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 10.10
Release:    10.10
Codename:    maverick

He echado un vistazo /var/log/dmesgy /var/log/pm-suspend.log, pero no sé lo que estoy buscando y nada destaca. No estoy seguro de si está relacionado, pero encontré mucho de lo siguiente en /var/log/kern.log:

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600
linux debugging suspend Steven D
fuente
1
Si cree que está siendo mordido por el error específico que menciono aquí, no publique una respuesta "yo también", ya que realmente no es una respuesta. Siéntase libre de votar esta pregunta para alentar a otros a responderla. Al final, una buena respuesta proporcionaría no solo consejos para resolver este problema en particular, sino también consejos para depurar este tipo de problemas.
Steven D
Eliminado después de la aclaración en Teachers 'Lounge. La única información potencialmente valiosa se No LSB modules are available.muestra justo después lsb_release -a.
Maciej Piechotka
Marqué una respuesta de "funcionó para mí", pero sigo pensando que una respuesta más general de "cómo depurar la suspensión a RAM" sería realmente útil aquí.
Steven D

Respuestas:

6

PM_DEBUG y PM_TRACE son aparentemente las instalaciones de depuración más profundas que existen en este momento. Cuando no obtiene nada significativo de los registros de nivel superior, AFAIK es el único mecanismo al que recurrir cuando se encuentra con el temido síntoma de "misteriosa pantalla en blanco al reanudar". La mayoría de las veces estamos lidiando con un controlador de dispositivo roto, con bastante frecuencia sutil. También puede echar un vistazo a mi saga de depuración del controlador inalámbrico Broadcom brcmsmac en el error del kernel 34682 para ver lo que los desarrolladores del kernel sugieren y buscan.

lkraav
fuente
1

Sospecho que el problema puede deberse a que el BIOS no informa correctamente sobre qué lowmem realmente usa.

Por defecto esta opción está vigente:

memory_corruption_check_size=64K

Puede intentar establecerlo en valores más grandes para hacer que el escáner de corrupción de memoria examine una gran parte de lowmem.

Busque "memory_corruption_check_size" en

etc.

Me interesaría saber lo que encuentras, si acaso.


fuente
0

Mi experiencia trabajando en esta área fue en Windows CE, en lugar de Linux.

Durante el ciclo de suspensión / reanudación, el sistema operativo cerrará progresivamente la funcionalidad del sistema operativo restringiendo su capacidad de obtener información confiable y precisa sobre lo que está sucediendo con la funcionalidad del sistema operativo. Además, su conexión de monitoreo puede (por ejemplo, si el problema está relacionado con el tiempo) alterar el resultado.

Las herramientas de preferencia comienzan con una conexión de depurador C / C ++ al sistema operativo en el extremo superior y en el extremo de nivel muy bajo enviando datos a un puerto serie / códigos POST o en un depurador JTAG de hardware que no sea X86 o equivalentes. El resultado final son largas horas resolviendo el flujo del código y encontrando el punto cuando se comporta de manera diferente al comportamiento normal. En ese punto, la solución suele ser obvia. Mantenga buenas notas y haga un cambio a la vez.

Nos llevó 6 semanas identificar el problema de encendido que teníamos con Windows CE. Teníamos una placa de procesador PC104 que podíamos apagar durante 10 o 60 segundos y encender sin problemas. Sin embargo, si se quitó la energía durante 25 segundos, no se encendería. Resultó que teníamos suficiente capacidad para mantener intactos los contenidos de la DRAM sin energía durante unos 20 segundos, por lo que en un corto ciclo de apagado, Windows CE pensó que se reanudaba desde un estado suspendido. Cuando se conservara toda la memoria, en realidad tendría éxito al realizar un currículum, cuando la memoria estaba parcialmente dañada, se confundiría bastante durante el currículum.

Buena suerte.

Michael Shaw
fuente