Page 1 sur 2
[FREEZE] Le système freeze aléatoirement
Publié : lun. 07 déc. 2015, 16:46
par lhenry
Bonjour à tous,
Hier, j'ai installé un Arch tout neuf sur mon nouveau Acer et j'ai rencontré quelques soucis. Au départ, il m'était impossible d'éteindre ou redémarrer la machine. Quand je tentais de le faire, la session X se terminait correctement, j'avais une petite barre clignotante tout en haut à gauche d'un écran tout noir. Après quelques secondes comme ça, le PC se met à ventiler +++ quelques secondes et s'arrête de ventiler. Il ne fait plus de bruit pendant quelques secondes et ventile à nouveau. Ce comportement se répète en boucle jusqu'à faire un hard reboot (rester appuyé sur le bouton d'allumage de la machine).
Après quelques heures de recherche, je pensais avoir réglé le problème avec cette manipulation :
https://wiki.archlinux.org/index.php/Ac ... own_freeze
Le soucis semble réglé concernant les démarrage/reboot sauf que maintenant, le PC semble freezer aléatoirement en cours d'utilisation. À deux reprises, l'écran s'est figé et impossible d'utiliser souris ou clavier. Même comportement de ventilation en boucle jusqu'à hard reboot. La première fois, je regardais une vidéo en streaming et la seconde je naviguais sur facebook.
Pour info, j'ai installé une distribution en 64bit avec Pantheon (En suivant ce tuto :
https://wiki.archlinux.org/index.php/Pantheon). Je donnerais ma configuration matériel dés que j'aurais la machine sous la main, dans quelques heures. Après mes nombreuses lectures, il me semble que certaines machines de chez Acer rencontrent ce problème avec les distributions de linux utilisant systemd.
Voilà, si des fois certains on des pistes pour m'éclairer un peu, il aurait droit à mon éternelle gratitude.
Par avance, merci à vous !
Re: [FREEZE] Le système freeze aléatoirement
Publié : lun. 07 déc. 2015, 23:43
par Ruskof
J'ai également le premier problème cité (freeze complet au déverrouillage de ma session après verrouillage) sur un PC Asus.
Merci pour avoir remonté cette aide.
Je te tiens au jus.
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 00:34
par lhenry
Salut,
merci pour la réponse. Du coup, avant de poster, en cherchant j'ai finit par :
-> Créé une partition swap (Je ne l'avais pas mis en place à l'installation)
-> Désactiver le support xCPI dans le BIOS (
http://spcmd.github.io/2015/05/24/Fix-A ... stros.html)
-> blacklisté 2 éléments du modprobe.d (
https://wiki.archlinux.org/index.php/Ac ... own_freeze)
C'est en faisant la troisième manip que j'ai réglé le problème chez moi après un premier redémarrage (Je viens de tester, il s'éteint/redémarre toujours correctement). Si des fois ça peut te servir.
Comme le problème persiste et est plus ou moins aléatoire, j'ai continué de fouiller et j'ai encore 2 choses à tester :
-> Ça (mais je sais pas vraiment de quoi il retourne, j'ai pas encore eu le temps d'approfondir.) :
http://linux.koolsolutions.com/2009/08/ ... -restarts/
-> ré-installer le système en EFI, j'ai lu quelque part que le problème pouvait venir de là mais bon, si il faut je ferais en dernier recours.
Avant de tester à nouveau des trucs, je voulais chercher un peu dans les fichier de log donc je me suis intéressé à la commande journalctl. Quand je tape la commande, j'obtiens ces lignes en rouge :
Code : Tout sélectionner
déc. 07 11:01:44 username systemd-coredump[1166]:Process 598 (gala) of user 1000 dumped core.
Stack trace of thread 598:
#0 0x00007f7f5e8d5734 meta_window_get_monitor (libmutter.so.0)
#1 0x000000000042e4db n/a (gala)
#2 0x00007f7f5bd891b9 n/a (libgobject-2.0.so.0)
#3 0x00007f7f5bd8b225 g_object_new_valist (libgobject-2.0.so.0)
#4 0x00007f7f5bd8b591 g_object_new (libgobject-2.0.so.0)
#5 0x000000000042fa6b n/a (gala)
#6 0x00007f7f5bd84015 g_closure_invoke (libgobject-2.0.so.0)
#7 0x00007f7f5bd96061 n/a (libgobject-2.0.so.0)
#8 0x00007f7f5bd9edfc g_signal_emit_valist (libgobject-2.0.so.0)
#9 0x00007f7f5bd9f12f g_signal_emit (libgobject-2.0.so.0)
#10 0x00007f7f5e8cf95c n/a (libmutter.so.0)
#11 0x00007f7f537bc1f0 ffi_call_unix64 (libffi.so.6)
#12 0x00007f7f537bbc58 ffi_call (libffi.so.6)
#13 0x00007f7f5bd84839 g_cclosure_marshal_generic (libgobject-2.0.so.0)
#14 0x00007f7f5bd84015 g_closure_invoke (libgobject-2.0.so.0)
#15 0x00007f7f5bd96061 n/a (libgobject-2.0.so.0)
#16 0x00007f7f5bd9edfc g_signal_emit_valist (libgobject-2.0.so.0)
#17 0x00007f7f5bd9f5f5 g_signal_emit_by_name (libgobject-2.0.so.0)
#18 0x00007f7f5e89e0d9 meta_monitor_manager_rebuild_derived (libmutter.so.0)
#19 0x00007f7f5e8a5298 meta_monitor_manager_xrandr_handle_xevent (libmutter.so.0)
#20 0x00007f7f5e8a0c2b n/a (libmutter.so.0)
#21 0x00007f7f5baafdc7 g_main_context_dispatch (libglib-2.0.so.0)
#22 0x00007f7f5bab0020 n/a (libglib-2.0.so.0)
#23 0x00007f7f5bab0342 g_main_loop_run (libglib-2.0.so.0)
#24 0x00007f7f5e8c7afc meta_run (libmutter.so.0)
#25 0x000000000041b6f4 gala_main (gala)
#26 0x00007f7f5b4c5610 __libc_start_main (libc.so.6)
#27 0x0000000000415d39 _start (gala)
Stack trace of thread 672:
#0 0x00007f7f5b58518d poll (libc.so.6)
#1 0x00007f7f5baaffbc n/a (libglib-2.0.so.0)
#2 0x00007f7f5bab00cc g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007f7f46bf525d n/a (libdconfsettings.so)
#4 0x00007f7f5bad6715 n/a (libglib-2.0.so.0)
#5 0x00007f7f5b8504a4 start_thread (libpthread.so.0)
#6 0x00007f7f5b58e13d __clone (libc.so.6)
Stack trace of thread 604:
#0 0x00007f7f5b58518d poll (libc.so.6)
#1 0x00007f7f5baaffbc n/a (libglib-2.0.so.0)
#2 0x00007f7f5bab00cc g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007f7f5bab0109 n/a (libglib-2.0.so.0)
#4 0x00007f7f5bad6715 n/a (libglib-2.0.so.0)
#5 0x00007f7f5b8504a4 start_thread (libpthread.so.0)
#6 0x00007f7f5b58e13d __clone (libc.so.6)
Stack trace of thread 690:
#0 0x00007f7f5b58518d poll (libc.so.6)
#1 0x00007f7f45dc1f51 n/a (libpulse.so.0)
#2 0x00007f7f45db3571 pa_mainloop_poll (libpulse.so.0)
#3 0x00007f7f45db3c0e pa_mainloop_iterate (libpulse.so.0)
#4 0x00007f7f45db3cc0 pa_mainloop_run (libpulse.so.0)
#5 0x00007f7f45dc1ee6 n/a (libpulse.so.0)
#6 0x00007f7f45b625f8 n/a (libpulsecommon-7.1.so)
#7 0x00007f7f5b8504a4 start_thread (libpthread.so.0)
#8 0x00007f7f5b58e13d __clone (libc.so.6)
Stack trace of thread 616:
#0 0x00007f7f5b58518d poll (libc.so.6)
#1 0x00007f7f5baaffbc n/a (libglib-2.0.so.0)
#2 0x00007f7f5bab0342 g_main_loop_run (libglib-2.0.so.0)
#3 0x00007f7f5c0a6236 n/a (libgio-2.0.so.0)
#4 0x00007f7f5bad6715 n/a (libglib-2.0.so.0)
#5 0x00007f7f5b8504a4 start_thread (libpthread.so.0)
#6 0x00007f7f5b58e13d __clone (libc.so.6)
À première vue, le problème semble venir de gala. Je sais pas vraiment ce que c'est comme truc, mais je vais m'y intéresser du coup. L'erreur est assez récurrente dans le journal et l'heure de la dernière correspond à peu près celle à laquelle le PC à planté tout à l'heure.
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 10:02
par Ruskof
Merci de ta réponse détaillée. A l'heure où je te réponds, je n'ai pas encore pu tester les différentes manipulations (cours et pas mal de taf).
Je tiens à préciser que j'utilise Arch Linux en dual boot avec W10, donc installer un système en EFI m'obligerait à refaire ma machine de A à Z
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 11:49
par lhenry
Pas de soucis.
Pour le coup, c'est aussi une solution que j'envisage en dernier recours, je dois aussi disposer d'un DualBoot avec un Windows pour mes études. Bon après, je peux me contenter d'une version virtualisé mais c'est pas top. Mon PC est pas surpuissant...
Sinon, me concernant, je penses que le problème vient de gala, qui est le gestionnaire de fenêtre utilisé pour Pantheon. À partir de là, j'ai deux nouvelles solutions à tester, à savoir :
-> Ajouter "gala" dans les "monitored-processes" de "cerbere" en utilisant "dconf-editor" (org.pantheon.desktop.cerbere)
-> tester si le problème persiste en supprimant la gestion des fenêtres via "gala", en lançant ma session X via gnome (remplacer le contenu du ".xinitrc" par "exec gnome-session")
Je mettrais à jour ce fil dés que ce sera fait.
[EDIT]
Je viens de refaire une installation propre (j'avais fait plein de manip, j'ai préféré recommencer...) du coup je confirme que concernant les Freeze à l'extinction ou au redémarrage, c'est bien la manip suivante qui corrige le problème chez moi :
Éditer le fichier
/etc/modprobe.d/blacklist.conf (Le créer s'il n'existe pas) pour y ajouter ces lignes :
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 15:46
par Ruskof
J'ai fait ta dernière manipulation (blacklist dmac et dmac_core), quand je verrouille mon PC, plus aucun problème au déverrouillage de la session.
J'ai verrouillé plusieurs fois d'affilée mon PC, aucun problème jusque là de freeze
Merci pour le tips, ça fonctionne aussi pour moi (PC Asus N55JX et dual boot W10/Arch Linux KDE)
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 19:16
par lhenry
Tout le plaisir est pour moi.
De mon côté, je sais pas trop si j'avance ou si je stagne. À la base, je pensais que l'erreur venait de gala, vu que je retrouvait une erreur récurente dans le journal donc j'ai entamé une démarche consistant à contourner le problème. En gros, je suis repassé sur un environnement gnme-shell en conservant les styles, icônes...normalement prévu pour pantheon. Le rendu est pas trop mal, même s'il manque 2 ou 3 détails.
La machina à tourné sans aucun problème toute l'après midi. Donc je pensais que c'était bon. Seulement en rentrant chez moi, rebelotte. Le PC freeze, ventile, arrête de ventiler, reventile en boucle.
Je regarde mon journal et cette fois, je tombe sur cette ligne :
Code : Tout sélectionner
i2c_hid i2c-SYN1B7E:00: failed to retrieve report from device.
En recherchant sur google, il s'avère que cette erreur est issue du pilote synaptic de mon touch pad. Du coup, j'ai blacklisté aussi le pilote du touchpad. Du coup il marche plus, je dois utiliser une souris pour l'instant.
Je vais tester comme ça pendant quelques jours pour voir si le problème est réglé ou pas et je reviendrais peut être sous pantheon à terme.
Je vais aussi regarder si des fois il existe pas un pilote libre pour mon touchpad.
Petite précision qui a certainement sont importance :
Ma machine est un Acer E5-511 équipé d'un écran tactile (Conflit possible entre les pilotes de l'écran tactile et le touchpad ?)
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 20:01
par lhenry
Bon c'était pas ça, la machine vient de me planter à nouveau 2 fois...
En tout cas, j'ai de moins en moins d'erreurs dans le journal.
Maintenant, il ne me reste plus que celle-là (sur les dernières minutes d'utilisation avant que ça plante :
Sauf que je très peu informations concernant cette erreur sur google.
Je sais plus vraiment quoi faire, je crois que je vais devoir abandonner Arch pour cette machine...
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 20:15
par benjarobin
Bonjour,
Tu veux dire Linux plus généralement, ArchLinux n’est en rien différente des différentes distributions Linux, à part un peu plus à jour.
Après pour ce genre de cas, il est difficile d'aider à distance, mais en gros je dirais que tu as des gros souci coté ACPI.
As tu fait l'installation en UEFI ou en legacy (MBR) ?
Est ce que ton BIOS est à jour ?
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 21:54
par lhenry
Salut,
Merci pour ta réponse. C'est pas la première fois en plus, j'ai souvent vu ton avatar se fracasser la tête en me répondant.
Ça fait chier pour linux, je dois avouer que l'idée de repasser sous windows n'est pas envisageable.
J'ai fais mon installation en Legacy, vu qu'à terme je vais avoir besoin d'un dual boot avec windows, l'EFI ne peut être que tempraire.
Je suis en train de me battre pour tenter une mise à jour de mon BIOS, mais c'est pas gagné. Ma clé veut pas booter en FreeDOS...
[EDIT]
Alors en fait, je toutes les version du BIOS que je trouve sont des executables. Les archives ne contiennent pas l'image de flashage comme ils le précisent ici :
http://www.linuxpedia.fr/doku.php/exper ... sh_freedos
Du coup, j'imagine que c'est à jour...
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 22:07
par benjarobin
Si tu as fait l'installation en Legacy, ne cherche pas plus loin, transforme ton installation en UEFI, car j'ai vu pas mal de rapport de bug indiquant que c'était la source du problème.
Sinon je n'ai pas compris cette phrase
lhenry a écrit : je vais avoir besoin d'un dual boot avec windows, l'EFI ne peut être que tempraire.
Depuis Windows 7, il n'y a aucun souci avec le support de l'EFI tant que le Windows est en 64 bits
lhenry a écrit :Du coup, j'imagine que c'est à jour...
Drôle de conclusion... Quelle est la version de ton BIOS (l'interface l'affiche normalement quelque part), et quelle est la référence exacte de ton PC
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 22:26
par lhenry
Alors là on touche à des truc que je ne maitrise pas trop et j'ai lu tellement de truc ces dernier jours que du coup je m'enbrouille en plus. Je pensais que l'UEFI ne permettait l'installation que d'un seul système... Je vais tenter ça du coup, mais comme je sais pas vraiment comment faire, je vais cherhcer une peu ce qui va me prendre du temps. Si des fois tu as un lien ou un source sous la main qui pourrait m'indiquer la marche à suivre, je suis prenneur.
Pour le BIOS, j'ai une version 1.02 visiblement et j'ai trouvé trois version plus récentes chez Acer pour ma machine, à savoir :
-> La 1.07 : Improved system performance (2015/01/27)
-> La 1.08 : Update legacy VBIOS for UMA (2015/06/10)
-> La 1.10 : Resolves Win10 brightness issue (2015/10/01)
Ma machine c'est un Aspire E5-511P.
J'ai d'abord tenté avec la 1.07, mais je n'ai qu'un .exe dans l'archive (Comme pour les autres que j'ai essayé ensuite. Du coup, je me suis dis qu'il fallait un windows pour le faire, donc la phrase "Du coup, j'imagine que c'est à jour..." était plutôt l'espression d'un dépit que d'une conclusion. Mea culpa.
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 08 déc. 2015, 22:43
par benjarobin
C'est une des raisons de garder un Windows installé (ou alors de choisir un Asus qui permettent une mise à jour du BIOS depuis le BIOS avec un simple clé USB en FAT32)
Pourquoi ne pas installer la dernière version (1.10) ?
Je te conseil de faire ceci : Sauvegarde tes données (voir carrément le disque dur entièrement), efface le disque dur, et créer une table de partition GPT vide avec gdisk.
Installe Windows 10 normalement (Tu peux récupérer le dernier ISO depuis le site de Microsoft, grave le CD et installe le normalement, il suffit de saisir la clé qui est inscrite sous le PC)
Met à jour ton BIOS en 1.10, puis réduit la partition de Windows 10 pour faire de la place à un Linux.
Installe ArchLinux en mode UEFI.
Re: [FREEZE] Le système freeze aléatoirement
Publié : mer. 09 déc. 2015, 20:22
par Ruskof
Je suis d'accord avec benjarobin, c'est une solution pour repartir de zéro de manière propre.
Re: [FREEZE] Le système freeze aléatoirement
Publié : jeu. 10 déc. 2015, 17:10
par lhenry
Bon j'ai mis un peu de temps mais j'ai finalement réussi à repartir sur une install propre.
Du coup, dans l'ordre, j'ai :
-> Formaté mon disque et créé une table de partition GPT sur l'ensemble du disque
-> Installé windows 10 (64 bits) en lui allouant 50Go. Il m'a bien recréé toutes les partition qu'il fallait.
-> Mis à jour mon BIOS
-> réinstallé un Arch (64 bits) en mode UEFI.
Je suis pas tout à fait certain d'avoir fait tout comme il faut, mais j'arrive à booter et à utiliser les deux systèmes.
J'étais plutôt confiant mais après plusieurs heures à configurer mon bureau, ça a replanté (J'étais en train de regarder une vidéo en streaming sur le net).
Du coup, j'ai fait un rapport de bug et on ma répondu en me renvoyant sur cette page :
https://bugzilla.kernel.org/show_bug.cgi?id=85931
Ça a l'air d'être assez proche de mon souci, mais j'ai l'impression qu'il n'y a pas encore de solution (Mais mon anglais est pas non plus excellent...)
Re: [FREEZE] Le système freeze aléatoirement
Publié : dim. 06 mars 2016, 18:55
par lhenry
Bon le problème semble s'être résolu à force de patience et de mises à jours.
J'ai encore quelques erreurs dans le journal, mais plus de freeze aléatoire pour l'instant. Je relancerais sûrement le sujet si ça revient.
Merci la communauté !
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 22 mars 2016, 11:44
par lhenry
Je retire...Le problème est de retour après quelques jours de tranquillité.
La je ne trouve plus aucune piste de travail, pour la première fois j'envisage d'abandonner l'idée de faire tourner cette machine sous linux...
Je suis un peu vert...
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 22 mars 2016, 12:12
par waitnsea
Bonjour,
Sous quel environnement travailles-tu ?
Avant de jeter le bébé avec l'eau du bain, peux-tu essayer avec un environnement light, LXQT par exemple mais il y en a d'autres, et si tu as encore des freeze, reposter avec des logs ?
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 22 mars 2016, 12:19
par benjarobin
L'environnement n'a strictement rien à voir avec son souci. Ici on a un souci à propos des événements ACPI qui sont mal gérés par le kernel.
Le rapport de bug indique que le kernel 4.5 corrige un des soucis, mais il y a encore des freezes. Je crains qu'il va falloir être patient pour avoir un kernel stable sur ce PC
Re: [FREEZE] Le système freeze aléatoirement
Publié : mar. 22 mars 2016, 12:38
par waitnsea
Effectivement j'avais raté ça :
intel_soc_dts_thermal: request_threaded_irq ret -22
pour la video ça coincera sous tous les environnements...
