Comment puis-je déboguer un problème de suspension sur RAM sous Linux?

J'espère obtenir des suggestions basées sur l'expérience sur la façon de déboguer le problème de suspension sur RAM. Des conseils spécifiques à ma situation (détaillés ci-dessous) seraient intéressants, mais je suis également intéressé par des conseils généraux sur la façon de déboguer de tels problèmes.

Le problème:

Souvent, lorsque j'essaie de suspendre ma machine, elle reste bloquée dans un état "non suspendu mais pas réveillé". Souvent, l'écran est complètement noir, mais parfois il y aura le message d'erreur suivant:

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

En outre, cet état sera également accompagné par les fans qui passeront à la vitesse supérieure. La seule façon de le sortir de cet état est d'éteindre manuellement l'ordinateur portable.

Des informations

$ 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

J'ai jeté un œil à /var/log/dmesget /var/log/pm-suspend.log, mais je ne sais pas ce que je recherche et rien ne se démarque. Je ne sais pas si c'est lié, mais j'ai trouvé beaucoup des éléments suivants dans /var/log/kern.log:

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600

Avez-vous un chipset graphique Intel? J'obtenais ce qui ressemble au même problème sur mes ThinkPad X200 exécutant Ubuntu 10.10, et cette solution de contournement (à partir de 2008!) L'a corrigé pour moi: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

PM_DEBUG et PM_TRACE sont apparemment les installations de débogage les plus profondes actuellement. Lorsque vous n'obtenez rien de significatif à partir de journaux de niveau supérieur, AFAIK, c'est le seul mécanisme à utiliser lorsque vous rencontrez le redoutable symptôme "écran blanc mystérieux à la reprise". Le plus souvent, nous avons affaire à un pilote de périphérique cassé, très souvent subtilement. Vous pouvez également jeter un œil à ma saga de débogage de pilotes sans fil Broadcom brcmsmac au bogue du noyau 34682 pour savoir ce que les développeurs du noyau suggèrent et recherchent.

Je soupçonne que le problème peut être dû au fait que le BIOS ne signale pas correctement quel lowmem il utilise vraiment.

Par défaut, cette option est en vigueur:

memory_corruption_check_size=64K

Vous pouvez essayer de définir cela sur des valeurs plus grandes pour que le scanner de corruption de mémoire examine un plus gros morceau de lowmem.

Recherchez "memory_corruption_check_size" dans

• http://lxr.linux.no/#linux+v2.6.35.7/Documentation/kernel-parameters.txt

etc.

J'aimerais savoir ce que vous trouvez, le cas échéant.

Mon expérience dans ce domaine était dans Windows CE, plutôt que sous Linux.

Pendant le cycle de suspension / reprise, le système d'exploitation arrêtera progressivement la fonctionnalité du système d'exploitation, ce qui restreindra votre capacité à obtenir des informations fiables et précises sur ce qui se passe à l'aide de la fonctionnalité du système d'exploitation. De plus, votre connexion de surveillance peut (par exemple, si le problème est lié au timing) modifier le résultat.

Les outils de préférence commencent par une connexion de débogueur C / C ++ au système d'exploitation à l'extrémité supérieure et à l'extrémité très basse envoyant des données via un port série / codes POST ou sur un débogueur JTAG matériel non X86 ou des équivalents. Le résultat final est de longues heures à travailler sur le flux de code et à trouver le point où il se comporte différemment du comportement normal. À ce stade, le correctif est généralement évident. Prenez de bonnes notes et apportez une modification à la fois.

Il a fallu 6 semaines pour identifier le problème de mise sous tension que nous avions avec Windows CE. Nous avions une carte processeur PC104 que nous pouvions éteindre pendant 10 ou 60 secondes et mettre sous tension sans problème. Cependant, si l'alimentation était coupée pendant 25 secondes, elle ne s'allumerait pas. Il s'est avéré que nous avions suffisamment de capacité pour garder le contenu de la DRAM intact sans alimentation pendant environ 20 secondes, donc lors d'un court cycle de mise hors tension, Windows CE pensait qu'il reprenait à partir d'un état suspendu. Lorsque toute la mémoire était préservée, cela réussirait en fait à effectuer un CV, lorsque la mémoire était partiellement corrompue, cela deviendrait plutôt confus pendant le CV.

Bonne chance.