[HAL] freez du système lors de débranchements USB ou autres

[adri]

Bonjour,

j'ai récemment migré de Gentoo à Arch Linux et bon, j'en suis pleinement satisfait même si les configurations sont vraiment différentes. Bon, point à part, voici mon problème qui persiste depuis pas mal de temps:


Mon système freeze complètement lorsque je suis sous gnome pour d'obscures raisons.

Quand ça freeze je peux encore bouger la souris, mais je ne sais même plus rebooter xorg, aucune touche du clavier semble marcher et la seule solution c'est de reseter la machine entière, pas de retour console possible, rien, aucune réaction!

Le gros du problème c'est que je n'arrive toujours pas à identifier exactement les causes: j'ai l'impression que c'est un problème avec HAL/ACPI/XORG.

Quand je débranche ma souris usb pour ensuite chipoter avec le touchpad, ça freeze. Lorsque je débranche l'alimentation secteur pour me déplacer un peu, et que je s'essaye de réutiliser le portable, ça freeze. Lorsque ma souris USB est enlevée, ça freeze de temps en temps.

C'est du méchant freeze et je n'ai réussi à rien identifier de concret dans les logs systèmes.

Et comme il y a un grand niveau de recherche je n'ai trouvé aucune solution.



Voici ce qui est déjà fait:

- enlever tout input de xorg.conf pour laisser hal s'en occuper.
- kernel compilé avec les bonnes options choisies (j'ai l'expérience de gentoo qui font en sorte que je suis certain de mon kernel)
- gnome installé par défaut avec le power-manager de gnome chargé à la session. (du coup pas de cpufreqd au démarrage ni de laptop-mode au démarrage.

Sinon tout fonctionne correctement...

Si quelqu'un pouvait m'aider ce serait bien sympathique


EDIT: la raison de mon post dans cette section est forcément que ça plantouille uniquement en environnement graphique

[tuxce]

salut, et sans démarrer "hal", ca freeze quand meme ?

et même en étant sur de ton kernel, comparer avec celui par défaut ne serait pas un luxe.

j'oubliais, utilises tu compiz ?

[Thom1]

Salut,

Dans le cas où tu aurais un autre pc chez toi, as-tu pensé à te loguer sur ta machine sous arch en ssh quand ça freeze ?
Comme ça, tu peux voir si linux même est complètement figé ou si juste xorg l'est, et donc voir les messages d'erreurs

[adri]

salut, et sans démarrer "hal", ca freeze quand meme ?

le problème c'est que si je n'utilise pas hal, je n'ai pas de périphérique d'input chargé vu que j'ai tout basardé de xorg.

et même en étant sur de ton kernel, comparer avec celui par défaut ne serait pas un luxe.

celui par défaut bug aussi

j'oubliais, utilises tu compiz ?

pas de compiz ni d'aiglx d'activé ni de metacity en composite... rien de lourd au niveau graphique, puis j'utilise les pilotes radeon (les libres).

Dans le cas où tu aurais un autre pc chez toi, as-tu pensé à te loguer sur ta machine sous arch en ssh quand ça freeze ?
Comme ça, tu peux voir si linux même est complètement figé ou si juste xorg l'est, et donc voir les messages d'erreur

Très bonne idée, j'y ai déjà pensé mais jamais trop pu le réaliser. Je pense que c'est que xorg qui freeze sans avoir trop de certitude, dès que je le peux, je tâcherai de faire ça.



Sinon je viens d'avancer un peu dans la découverte du pouquoi du comment...

Apparemment, l'erreur que je pensais être des débranchements usb ou du touchpad est en fait une erreur acpi, j'arrive à reproduire à 100% le freeze quand je suis en mode secteur et que je débranche le fil d'alimentation du portable.

Du coup petite question:

Est-ce que cette saloperie de gnome-power-manager ne serait pas en concurence avec acpid? vu que hal charge acpid automatiquement je me dis que y a peut-être un script quelque part en double ou qui met un verrou sur quelque chose et dont l'autre bloque dessus. Enfin, je vais me renseigner plus sur ce cas.


Merci beaucoup pour vos réponses!

[tuxce]

le problème c'est que si je n'utilise pas hal, je n'ai pas de périphérique d'input chargé vu que j'ai tout basardé de xorg.

normalement, xorg n'utilise pas hal mais udev, c'est gnome qui utilise hal mais justement, c'est pour s'assurer que ca vient de la (ou pas).

Est-ce que cette saloperie de gnome-power-manager ne serait pas en concurence avec acpid? vu que hal charge acpid automatiquement je me dis que y a peut-être un script quelque part en double ou qui met un verrou sur quelque chose et dont l'autre bloque dessus. Enfin, je vais me renseigner plus sur ce cas.

gnome-power-manager n'est pas en concurrence avec acpid mais il peut l'etre avec les outils cpufreq mais si tu n'as pas chargé le module cpufreq_userspace, il ne peut pas changer les fréquences et normalement ne bloque pas pour autant (en tout cas pas le ctrl+alt+backspace)
d'un autre coté, il suffit de l'enlever des programmes de sessions ou tout simplement le killer pour le désactiver et vérifier si ca vient de la.

as tu modifié le /etc/acpi/handler.sh ?


il faudrait vérifier /var/log/everything.log voir s'il n'y a pas de message pouvant mettre sur la piste.

si tu remets le secteur, ca se rétablit ?

tu peux aussi voir du coté de http://wiki.archlinux.fr/howto:kernel:sysrq pour débloquer.

[_alexmyself]

ouah le vieux souvenir de problème d'un coup !!
essaie de mettre 'noapic' comme parametre de boot du kernel.

j'ai eu très exactement le même souci il y a plusieurs mois(années?) et ça à mis un bout de temps à être fixé.

ton install est a jour?

[adri]

rebonjour, je n'ai pas pu répondre à toutes vos suggestions par manque de temps.

Entre temps mon problème s'est réglé plus ou moins, et du moins j'ai découvert enfin le déclencheur exacte!

ça se déclanche quand, j'enlève ma souris usb et que j'utilise le touchpad, maintenant le touchpad fonctionne très bien. Donc je pense que c'est bien au niveau de mon kernel que ça coince, sans doute qu'il faut que je désactive l'émulation souris en /dev/psaux pour le résoudre. Je vais essayer ça ce soir.

Sinon une mise à jour de xorg vient de rétablir l'harmonie dans mon système.

merci à vous tous pour votre aide précieuse. Je vous donne des nouvelles