Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Debian, et suspend-to-disk

2 réponses
Avatar
Doug713705
Bonjour à toutes, tous,

J'avais déjà posté une demande sur ce point mais il me semble qu'elle
était restée sans réponse, c'est pourquoi je réitère.

Je dispose d'un système Debian Squeeze totalement à jour et strictement
d'origine (aucune bidouille hasardeuse ou tentative de forçage d'aucune
sorte n'a été effectué sur ce système) qui a vraiment du mal à se
récupérer après une mise en veille prolongée (suspend-to-disk) et je
n'arrive pas à savoir d'où cela peut venir.

J'ai l'impression (mais ce n'est qu'une impression) que la partition
swap n'est pas forcément correctement détectée[1] et fait planter le
processus de récupération du système.

Toujours est-il que j'aimerai savoir comment définir correctement cette
partition pour que le système retrouve ses petits au plus tôt.

Sur une Slackware, j'aurai volontiers recompiler le noyau pour y
indiquer la partition de swap (je n'ai plus l'option précise en mémoire
mais je sais que je l'ai déjà fait) mais cette méthode me semble bien
brutale.

J'ai bien vu/lu qu'il existait une option pour grub2 pour indiquer au
noyau cette même partition mais tous mes essais se sont révélés
infructueux (je n'ai pas oublier de faire un update-grub2).

Existe t-il une autre méthode ?

J'ai également lu que certains modules du noyau peuvent poser problème
lors de la mise en veille.

Le seul qui me semble problématique est celui lié au blue-tooth (des
messages d'erreurs s'affichent lors de la mise en veille) mais malgré
son 'black-listage' afin déviter qu'il soit chargé au démarrage, le
problème persiste (de toutes façons, le problème pouvait ne _pas_
survenir malgré les messages d'erreur).

Autre probabilité, j'utilise ndiswrapper mais celui-ci ne semble pas
poser de problème.

La machine est un eeePC (Intel Atom N270)
Le système est une Debian Squeeze à jour
Le noyau est un 2.6.32-5-686 SMP

[1] Il arrive de manière aléatoire que le système se récupère
parfaitement mais il m'a été impossible d'en déterminer la cause.

Merci pour tous vos conseils et pistes.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://www.dougwise.org
http://usenet-fr.dougwise.org
http://news.dougwise.org

2 réponses

Avatar
yamo'
Doug713705 a tapoté, le 12/09/2011 06:25:
La machine est un eeePC (Intel Atom N270)



J'ai un eeepc 1005HA et l'hibernation déconnait, c'est un bug référencé
et apparemment il est résolu, il faudrait que je teste pourvoir si c'est
bien le cas :
<https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745304>


Peut-être est-ce que ce bogue est partagé par Debian.

--
Stéphane

<http://pasdenom.info/fortune/>

Tu es assis près d'un ruisseau et tu as soif.
Même si tu es idiot, tu sais que l'eau va te désaltérer.
C'est ça comprendre..
-+- René Barjavel -+-
Avatar
Doug713705
Le 12-09-2011, yamo' nous expliquait dans
fr.comp.os.linux.configuration :

Doug713705 a tapoté, le 12/09/2011 06:25:
La machine est un eeePC (Intel Atom N270)



J'ai un eeepc 1005HA et l'hibernation déconnait, c'est un bug référencé
et apparemment il est résolu, il faudrait que je teste pourvoir si c'est
bien le cas :
<https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745304>


Peut-être est-ce que ce bogue est partagé par Debian.



Hmmm, ce problème n'existait pas au temps où mon eeePC était sous
Slackware (mais il est vrai avec un noyau plus récent).

J'avais déjà vu ce rapport de bug lié au driver vidéo mais je ne sais
plus pourquoi j'avais écarté cette hypothèse (et je n'ai pas d'accès à
internet suffisemment fiable pour pouvoir re-vérifier immédiatement).

Merci pour la piste.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://www.dougwise.org
http://usenet-fr.dougwise.org
http://news.dougwise.org