I
impaire

  • 20 mars 2016
  • Inscrit 31 déc. 2009
  • 0 meilleure réponse
  • Petit nouveau Adepte du forum Rédacteur potentiel
  • redj12 wrote:Lorsque j'ouvre une fenêtre elle s'affiche en saccadé. Le seul moyen c'est de redémarrer et ça devient insupportable, surtout que c'est sur un SSD. L'utilisation du processeur n'a rien d'anormal.
    redj12 wrote:Merci pour votre aide. J'ai désactivé les modules de FF mais rien ne se passe. J'utilisais top pour voir la mémoire utilisé mais en fait, en regardant avec le moniteur de système j'ai trouvé ça :

    http://pix.toile-libre.org/upload/thumb/1457378262.png

    788 Mo tout de même. (HS: comment on fait pour....
    En fait, là dedans, je vois surtout gnome-shell très occupé. 41% de CPU. Pourquoi? ET les 788Mo de RAM, c'est gnome-settings-daemon, pas Firefox...

    Les quelques commande, plus haut, permettraient de savoir s'il y a des activités disque élevées, voire des iowait. Mais j'irais d'abord voir les logs (journalctl ou /var/log/messages) s'il n'y figure rien d'anormal.

    Peut-être qu'avec les commandes suivantes, il pourrait y avoir des réponses:
    journalctl /usr/bin/gnome-shell
    
    journalctl /usr/bin/gnome-session
    
    journalctl /usr/bin/gnome-settings-daemon
    D'autres ont eu des problèmes avec leur driver vidéo, ou avec une accélération software plutôt que matériel, ça pourrait aussi expliquer des ralentissements, des lenteurs de l'affichage (qui ne signifie pas lenteur globale du système, ni problème éventuel de disque):

    https://www.google.fr/search?q=gnome-shell+high+cpu
  • Moins on (re)écrit sur un SSD, mieux c'est. Les générations actuelles seraient plus durables. Le minimum, à mon avis:

    - pas d'hybernation
    - pas de swap (utiliser ou étendre la RAM)
    - pas de /tmp (utiliser la RAM, un tmpfs)
    - noatime

    J'ai vu que noatime pouvait poser problème avec des utilitaires. Et qu'il existe une variante pour ne modifier les statuts des fichiers que une fois par jour.

    J'ai pas trouvé d'options simples pour modérer les logs. SE Linux et tout ça, c'est super bavard...

    Un Linux qui coince alors que la CPU n'est pas à 100%, je pense en premier à un périphérique qui le bloque. Le disque HS, c'était flagrant, le PC mettait de 30 à 45 min pour finir de booter, et il y avait plein d'erreurs à la console et dans les logs (qui en ajoutait au stress du disque). Il n'y a rien dans le journal pendant que ça coince?
    # journalctl -f
    -- Logs begin at Thu 2016-02-18 22:10:19 CET. --
    Mar 19 19:55:17 ...
    Peut être avec iotop? Ou d'autres commandes en rapport avec des entrées/sorties?
    # iotop
    
    Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
    Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
      TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
        1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd --switched-root --system --deserialize 21
        2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
     1027 ...
    Sinon, voir avec le pack sysstat... %iowait pourrait être différent de 0?
    # dnf install sysstat
    
    # iostat
    Linux 4.4.5-300.fc23.x86_64 (***)     03/19/2016      _x86_64_        (2 CPU)
    
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               0.99    0.02    0.14    0.04    0.00   98.81
    
    Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
    sda               2.77        29.40        11.29     365274     140321
    sdb               0.24        24.72         0.00     307100         29
    dm-0              0.80        13.44         0.37     166993       4632
    dm-1              2.37        15.05        10.92     186973     135656
    dm-2              0.01         0.17         0.00       2141         32
    
    Après, c'est plus compliqué...
    # sar -q
    Cannot open /var/log/sa/sa19: No such file or directory
    Please check if data collecting is enabled
    
    pidstat pour savoir qui fait quoi avec le disque? Bref, tout ce qui afficherait des stats, des états...
    # pidstat -d
    Linux 4.4.5-300.fc23.x86_64 (***)     03/19/2016      _x86_64_        (2 CPU)
    
    08:54:06 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
    08:54:06 PM     0         1     10.14      0.38      0.00      12  systemd
    08:54:06 PM     0        92      0.03      0.00      0.00     215  kworker/u4:3
    08:54:06 PM     0       384      0.00      0.12      0.00       8  jbd2/dm-0-8
    ...
  • gnome shell à 41% CPU? Qu'est-ce qui l'occupe à ce point?

    La seule fois où j'ai vu un Linux ralentir vraiment sans raison apparente, son disque dur était mort. Un disque non SSD. Ca passait son temps à tout relire jusqu'à ce que ça passe...

    Il pourrait y avoir des réponses au journal ou dans /var/log/messages
  • Rockmyu wrote:
    Oops!
    We're sorry, it looks like /usr/lib/firefox/plugin-container crashed.
    Je ne vois pas trop le rapport...
    Moi non plus. T'es tout seul à ton PC? :-D
    Rockmyu wrote:Lorsque je boot en 4.2.3 ça fonctionne niquel mais je ne peux plus régler la résolution de l'écran...

    C'est Fedora qui est chiant ? parce que sur Ubuntu je n'avais aucun problème...
    Tu parles d'une autre version de kernel? De l'une à l'autre, ça peut fonctionner différemment... Si tel est le cas, tu aurais donc le choix: pas d'écran, ou pas de changement de résolution d'écran.

    Un fichier xorg.conf pourrait peut être te résoudre ce problème d'écran principal.
  • Si tu arrêtes gdm (systemctl stop gdm) juste après le boot, il se passe quoi, le moniteur principal est où? VGA ou DP?

    Vois avec xrandr, quels sont les paramètres détectés et acceptés par tes deux moniteurs.

    Puis essaye avec Xorg.conf, pour forcer le moniteur primaire de cette façon là... Il faut définir un layout, les screens, etc, vérifier si 0 est bien le primary, ou s'il faut d'autres trucs:
    Section "ServerLayout"
        Identifier     "Layout0"
        Screen      0  "Screen0"
        Screen      1  "Screen1" RightOf "Screen0"
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Mouse0" "CorePointer"
    EndSection
    
    ...
    Section "InputDevice"
    
        # generated from default
        Identifier     "Mouse0"
    
    
    ...
    Section "Monitor"
        Identifier     "Monitor0"
        VendorName     "Unknown"
        ModelName      "Unknown"
        HorizSync       28.0 - 33.0
        VertRefresh     43.0 - 72.0
        Option         "DPMS"
    EndSection
    
    Section "Device"
        Identifier     "Device0"
        Driver         "nvidia"
        VendorName     "NVIDIA Corporation"
        Option      "TwinViewXineramaInfoOrder" "DFP"
    EndSection
    
    Section "Screen"
        Identifier     "Screen0"
        Device         "Device0"
        Monitor        "Monitor0"
        DefaultDepth    24
        Option         "TwinView" "true"
        Option         "MetaModes" "nvidia-auto-select, nvidia-auto-select"
        SubSection     "Display"
            Depth       24
            Modes         "1920x1200"
        EndSubSection
    EndSection
    
    ...
  • fgland wrote:bien docteur, je me garderai d'intervenir
    Cela ne m'empêche pas de dire que gdm est lourding et qu'il devrait se contenter de faire le gestionnaire de connexion
    au revoir
    Non, continuez. Je vous invitais juste tous ou de façon plus générale à être un peu plus prudent. Je pars du principe que le groupe gnome est un ensemble cohérent, et qu'avant d'en supprimer quelque chose, il vaudrait mieux faire quelques vérifications, sur ce qui bouffe la CPU (ou autre), lorsque ça se produit. Surtout si gdm en fait plus, comme vous le dites...

    J'ai gdm sur cette machine là, une FC21; qui ne m'a jamais posé le moindre problème, et la CPU est à 0,2%:
    top - 19:10:57 up 9 days, 21:36,  4 users,  load average: 0.01, 0.03, 0.05
    Tasks: 194 total,   1 running, 193 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.2 us,  0.2 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
    
    # systemctl status gdm
    ● gdm.service - GNOME Display Manager
       Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
       Active: active (running) since Tue 2016-02-02 21:35:02 CET; 1 weeks 2 days ago
    
    J'ai vérifié sur une FC23. Un peu chargée, entre 6 et 15%. De temps en temps seulement, je vois passer gnome-shell à 1,7%, pour le reste, il est à 0%. Si ça montait, je commencerais par chercher pourquoi, pas par le supprimer.
  • J'ai eu ce même problème, après reflash d'un bios. Tout a été purgé, avec paramètres par défaut.

    Je m'en suis sorti par hasard, sans réinstall. J'ai passé le BIOS en mode Legacy, pour booter sur une clef USB de recue. Puis j'ai remarqué un premier changement dans le BIOS, le Linux réapparaissait. J'ai repassé le BIOS en UEFI. Puis tout allait bien, le BIOS/UEFI connaissait Linux, pouvait booter.
  • nouvo09 wrote:
    Ca indexe les données présentes sur le disque?
    Oui c'est updatedb qui s'en charge.
    Si un process ou dgm travaille, trouve des erreurs, et les notifie via gdm pour que ce soit enregistré dans les logs, gdm finira lourd et/ou présent dans les logs...

    Je veux juste illustrer par là que ce n'est pas forcément en supprimant/remplacant gdm, ou un élément d'un ensemble, que ce genre de problèmes peut être facilement résolu. Procéder de cette façon peut occulter des problèmes et parfois même en agraver.

    Pour le probleme d'octobre, il aurait été préférable de voir d'abord mieux ce qu'il se passait côté indexation. Ou de façon plus générale, en cas de problème, lorsque c'est possible, essayer de voir d'abord ce que fait un process, voir ses logs, et ensuite seulement prendre des décisions - laisser faire ou finir, redémarrage, changement, upgrade, etc.

    Google peut être utile. Copier/coller 3 mots clefs peut souvent suffire pour trouver des éléments de réponse ou utiles à une analyse.
  • Le systemctl status affiche une partie des infos. Une partie de ce qui t'intéresse est là, et est à décoder:

    feb 12 14:49:44 rocksteady mcelog[932]: Hardware event. This is not a software error.
    feb 12 14:49:44 rocksteady mcelog[932]: MCE 1
    feb 12 14:49:44 rocksteady mcelog[932]: CPU 0 BANK 6
    feb 12 14:49:44 rocksteady mcelog[932]: MISC 38a0000086 ADDR fef85fc0



    Et pour les décoder, en attendant mieux, des explications sont donc là: http://www.advancedclustering.com/act-kb/what-are-machine-check-exceptions-or-mce/

    Il doit y en avoir 3, comme ça, selon les time stamps. Chacune correspondant à ces trois lignes:

    [ 0.042931] mce: [Hardware Error]: Machine check events logged
    [ 300.854209] mce: [Hardware Error]: Machine check events logged
    [ 8070.412484] mce: [Hardware Error]: Machine check events logged


    Dans ton log, je vois en dernier:

    feb 12 14:49:44 rocksteady systemd[1]: Started Machine Check Exception Logging Daemon


    Il n'a rien enregistré/décodé de plus car mcelogd n'avait pas encore démarré? Il peut y avoir un problème de conf.

    Sinon, qu'affiche ce qui suit? Toutes les lignes d'info mcelog qui t'intéresseront?
    journalctl -u mcelog
  • Dans l'immédiat, je ne peux pas vérifier. Mais j'ai l'impression qu'il y a deux choses, "mce" et "mcelog". Le premier pourrait être une fonction du kernel ou au boot, qui alimente le second, mcelog, qui traitera les informations détectées.

    Ne manquerait-il pas un service? mcelog ou mcelogd? C'est ce que l'info semble expliquer:
    Most likely reason is that mcelog is not installed or not configured
    to be started during boot.
    Without this tool running, the binary data saved by kernel
    is of limited usefulness.
    

    Un dmesg |grep -i "machine check", ça dit quoi? Les infos doivent être codées. Et mcelog sert à les décoder.

    Une page avec des explications: http://www.advancedclustering.com/act-kb/what-are-machine-check-exceptions-or-mce/
  • Ce n'est pas une question de lourdeur, mais de tâches que doit effectuer gdm (ou un quelconque autre process). J'ai gdm, je n'ai pas eu le sentiment qu'il était "lourd". Pas remarqué non plus mes CPU à 25% avec le PC au repos.

    Quand vous rencontrez ce genre de soucis, vérifiez les logs et pensez à Google aussi. Avec Google, et à partir de quelques mots clefs, on trouve parfois vite des pistes pour faire des vérifications.


    J'ai survolé rapidement le problème décrit en octobre dernier. Je ne suis pas un spécialiste de Fedora ni de Gnome. Ca indexe les données présentes sur le disque?

    Vu l'erreur rapportée en octobre, sur les trackers, ça ne ressemblait pas à un problème de gdm. gdm rapportait plutôt des erreurs décelées par un process tiers. Et changer gdm a pu occulter des erreurs (probablement pas très graves). Il pouvait y avoir d'autres choses à faire ou à vérifier avant:

    https://ask.fedoraproject.org/en/question/61450/huge-amount-of-tracker-warning-log-lines-upon-login/ I am not sure what is wrong with the metadata from that output, but if you just want to stop the error messages, it's easiest to use the package called tracker-preferences. It can be launched from a terminal using the command of the same name.

    With that program, you can choose to make tracker ignore specific directories when indexing, or you can exclude file types using * as a wildcard, for example *.jpg to exclude jpeg files from indexing. That will at least stop the error messages from filling up your journal needlessly.
    photino wrote:Depuis la fedora 23, gnome-shell (GDM) consomme beaucoup de CPU (environ 25 % avec juste la session lancée) . Est-ce normal ?
    Quoi comme type de CPU, d'abord? Pour pourvoir dire si c'est normal ou non, il faut arriver à cerner ce qui occupe tant gdm. Il y a peut-être quelque chose à corriger ou à modifier avant de changer gdm pour plus "light".
  • Alors sans l'enregistrer, en l'ajoutant tout au démarrage du PC uniquement, essaye HDMI d (disabled). Déja pour voir s'il arrive alors à fonctionner avec uniquement l'écran du portable.
    video=LVDS-1:D video=HDMI-1:d
    Si ca fonctionne, il te suffirait de réactiver le HDMI après le boot, par script. Ca peut peut-être fonctionner.

    Essaye HDMI d, boote. Si t'as du bol, tu bootes sur l'écran du PC et tout va bien. Puis lorsque tu brancheras l'HDMI, Xorg le détectera. Si t'as du bol. Sinon, tu vas devoir chercher un peu encore.
  • antbel wrote:Jacq rame-t-il toujours ? Telle est la question ?
    Il risque d'avoir besoin d'un coup de main. Surtout s'il a eu un problème similaire au mien (perte des données EFI Microsoft) et s'il n'a pas envie de réinstaller Windows (en risquant de foirer son install Linux).

    Le BIOS vient de me faire une farce. Après un reset to defaults, il a oublié qu'il existait Linux (et grub), bootait d'office Win, ne proposait plus autre chose. En cherchant à booter sur une rescue, je suis passé ponctuellement en mode BIOS Legacy plutôt que EFI. Au retour de Legacy vers UEFI, il a redétecté Linux (et grub). Mon dual boot re refonctionne...

    Jacq pourrait donc peut être aussi regarder ce que le BIOS lui propose lorsqu'il change ses modes Legacy/UEFI. Ca lui redétectera éventuellement son Windows.

    Je n'y toucherais plus maintenant. Ca devrait aller bien.
  • Regarde aussi ce qu'est Conky si tu veux personnaliser ton bureau. Ensuite, ce sont des applis en plus, selon les besoins. Ou autre chose que Gnome, selon les gouts, voire les besoins. KDE?

    Si tu débutes, commence par te documenter un peu puis par te familiariser avec ce que tu as sur ton PC. Peut être qu'ensuite, tu auras effectivement envie de réinstaller à tes gouts ou selon tes besoins. Je pense que hormis des choses assez spécifiques (serveur, sciences, programmation, traitements graphiques ou vidéo, son...) tout le monde installe au minimum la base Workstation, sans rien en supprimer.
  • Essaye HDMI D et LVDS D, pour forcer HDMI actif même en l'absence de moniteur...
  • Sinon, au moment du boot, lorsqu'il y a les choix à l'écran, il est possible d'éditer la ligne qu'on choisit. On ajoute alors l'option, puis on boote. Si c'est bon, ce sera à ajouter au fichier.
  • Jacq wrote:Bonjour,

    Suite à un gros bogue non-résolu, j'ai du refaire une installation de Fedora.
    J'étais, avant ce bogue, en dual boot windows 8.1/Fedora 22.
    Qu'as tu dans le répertoire /boot/efi/EFI? Juste fedora ou Microsoft aussi?


    Moi, j'ai pu faire une connerie lors d'une install de la fc23. Les partitons Win étaient alors bien à part, au GUI.

    Par contre, la partition EFI est commune et devait être affichée parmi celles de la fc23. Lors d'une install de la fc23, j'ai pu demander un formatage de la partition EFI. Puis perdre ces éléments EFI de Win...

    Je viens de réinstaller Win. En ne formatant que sa partition data/soft. La partition EFI a maintenant à nouveau un dossier Microsoft (bien rempli). Et à présent, grub2mkconfig détecte Win:
    # ls /boot/efi/EFI
    BOOT  fedora  Microsoft
    # ls /boot/efi/EFI/Mi*
    Boot  bootmgfw.efi  Recovery
    
    # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
    Generating grub configuration file ...
    
    ...
    Found linux image: /boot/vmlinuz-4.3.5-300.fc23.x86_64
    Found initrd image: /boot/initramfs-4.3.5-300.fc23.x86_64.img
    
    ...
    Found Windows Boot Manager on /dev/sda2@/EFI/Microsoft/Boot/bootmgfw.efi
    done
    
    Ca s'est finalement bien passé. Il me reste à vérifier grub au boot.

    Mais j'ai perdu l'install précédente Windows. Win me proposait cependant de la conserver dans un .old. Je pense que si j'y avais eu des données importantes, j'aurais pu les récupérer.
  • Je viens de lui insérer le DVD de réparation, puisqu'il insistait. Ca me fait la même chose que avec grub2 et os-prober? Leur utilitaire essaye mais ne peut rien réparer. A partir d'un point de restauration non plus, il ne semble pas avoir repéré une précédente install. On dirait que quelque chose a disparu du disque...

    Edit... Réinitialiser le PC, en conservant les fichiers, il veut bien, presque. Il me dit: "Le lecteur où Windows est installé est verroullé. Déverouillez le lecteur, puis réessayez."

    Voilà :hammer:

    Ah... Il confirme. Réinitialiser le PC, en effaçant toutes les données: "Impossible de réinitialiser votre PC. Une partition de lecteur requise est manquante." Je pense que c'est la partition EFI qui ne lui plait pas.
  • J'ai pu ajouter ntfs.mod sur la partition EFI. Ensuite, aprèsinsmod ntfs, j'ai pu lister le contenu de la partiton Win depuis grub(2).

    Par contre, je ne peux pas booter Win. Il me manque ntldr.mod version X86_64, ça n'existe qu'en i386 qui n'est pas compatible avec cette version de grub (message d'erreur). dnf ne trouve pas autre chose que la version i386...

    Je pense à insérer le DVD, pour réparation de WIN. Je ne suis pas sûr de retrouver ensuite le Linux, donc j'hésite.

    Edit... Je viens de faire autrement qu'avec ntldr. Le windows bootmanager démarre, me dit qu'un truc est cassé, et me demande de booter sur le CD de réparation.
  • Je l'ai mis en résolu, puisqu'il est possible de générer les core dumps.