Bonjour,

Je cherche depuis quelques jours à faire parler la Fedora, lorsqu'elle "freeze" du fait d'un plantage vidéo. Quand le PC est planté, plus rien ne va. Il ne réagit même plus à un SysReq.

J'essaye de voir si ça peut générer un crash dump au freeze. Il y a d'autres moyens pour que Fedora ou Linux affiche des messages d'erreurs en cas de fresse ou blocage?

Il n'y a aucun moyen pour rendre ce système plus bavard lorsqu'il freeze ou se plante? J'ai essayé netconsole: rien: l'écran, le réseau, tout est bloqué lorsqu'il freeze.

J'ai pu booter avec 4.3.5-300.fc23.x86_64+debug et j'essaye de voir s'il y aura un crash dump suite à freeze. Pour activer kdump, tout est expliqué ici:

How to use kdump to debug kernel crashes https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
# uname -a
Linux ** 4.3.5-300.fc23.x86_64+debug #1 SMP Mon Feb 1 03:02:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

# systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2016-02-09 12:51:45 CET; 3s ago
  Process: 3388 ExecStop=/usr/bin/kdumpctl stop (code=exited, status=0/SUCCESS)
  Process: 3559 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 3559 (code=exited, status=0/SUCCESS)

Feb 09 12:51:40 *** systemd[1]: Starting Crash recovery kernel arming...
Feb 09 12:51:45 *** kdumpctl[3559]: kexec: loaded kdump kernel
Feb 09 12:51:45 *** kdumpctl[3559]: Starting kdump: [OK]
Feb 09 12:51:45 *** systemd[1]: Started Crash recovery kernel arming.
Je te la remet ici au cas où :
La 4.5 est disponible sur la rawhide officiellement.

Après à voir où tu la prend.

Il y a pas mal de différence, cela demande sans doute les mises à jours des pilotes, serveur graphique xorg/wayland, libdrm, compilateur llvm, etc...

Tu peux faire un tour dans le répertoire de log ou avec "journalctl" (voir les différentes options dans le man) pour savoir ce qui plante.
VINDICATORs wrote:Tu peux faire un tour dans le répertoire de log ou avec "journalctl" (voir les différentes options dans le man) pour savoir ce qui plante.
Justement, ça n'affiche absolument rien, nul part. Lorsqu'il est planté sur un de ces problèmes de vidéo, le PC est complètement mort.
journalctl --list-boots
journalctl -b
journalctl -b -1
Il vient de planter, vers 14h00, certainement sur un problème de vidéo. Au journal, il n'y a rien que des banalités. Je venais tout juste d'ouvrir un teminal, il y a eu freeze et je l'ai rebooté. Au journal, il n'y a rien de récent à part des messages sur l'ouverture du terminal, sous gnome.

Et pas de crash dump, il ne s'est rien passé. Le PC ne réagissait pas non plus à SysReq.

Je viens de le freezer après ce reboot. Autrement, en tripotant SysReq. Et le PC ne réagit maintenant plus à rien. Je voudrais qu'il affiche quelque chose lorsqu'il se bloque...

Pour le moment, il n'y a plus que le clavier USB qui semble être actif. NumLock: la LED s'affiche ou s'éteint.
Je l'ai donc planté en tripotant SysReq. Peut être qu'avec un mode d'emploi, ça se passera mieux une prochaine fois...

Dealing With a Frozen X Server If your X server (the program that runs your graphical desktop) freezes, you may find yourself unable to use your system. There are a few magic SysRq commands that can help:
http://www.howtogeek.com/119127/use-the-magic-sysrq-key-on-linux-to-fix-frozen-x-servers-cleanly-reboot-and-run-other-low-level-commands/
VINDICATORs wrote:Tu peux faire un tour dans le répertoire de log ou avec "journalctl" (voir les différentes options dans le man) pour savoir ce qui plante.
J'ai trouvé un truc simple pour tuer le PC juste à la souris, en 3 clics, en ne faisant rien d'exceptionnel. Le pilote graphique... Et le PC ne m'affiche plus rien nul part, même le clavier est tout à fait inactif. On dirait que ce sont des cas qui peuvent se produire:

Enabling KMS via either "options i915 modeset=1" in /etc/modprobe.d/i915-kms.conf or "modprobe i915 modeset=1, /etc/init.d/gdm start" leads to a system-wide freeze (hard-off or SysReq B (only that key works)). Mode change apparent in console. Testing shows that hang starts at X startup. No debugging obtained yet locally or by remote (many tries) and nothing entered in logs, but binary and misplaced text is injected into "messages" and other logs. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/387978

Je ne pense pas que j'arriverais à en tirer plus après ces essais.
Dans /var/log "message" (en root, à tout les coups tu regarde en utilisateur et pas en superutilisateur. tape "su -" avant d'aller regarder!) devrait retourner un truc comme quoi la puce graphique à planté, voir autre chose.

C'est tout de même étonnant ce genre de plantage au bout d'un moment sans rien faire de particulier.
VINDICATORs wrote:Dans /var/log "message" (en root, à tout les coups tu regarde en utilisateur et pas en superutilisateur. tape "su -" avant d'aller regarder!) devrait retourner un truc comme quoi la puce graphique à planté, voir autre chose.
J'ai pas de /var/log/message. Tout est dans le journal. Où il n'y a rien de particulier. J'ai même essayé des kernels et paramètres avec plus d'infos dans le journal, mais ça ne m'a rien affiché de plus lors d'un blocage.
VINDICATORs wrote:C'est tout de même étonnant ce genre de plantage au bout d'un moment sans rien faire de particulier.
Quand je le laisse tourner tout seul après un reboot, il fini par planter, au bout de 30 minutes à 3 heures.

Mon truc pour tuer le PC immédiatement est maintenant tout simple. Je l'ai fait trois fois, ça plante à tous les coups:

- je l'allume, il boote
- X démarre, autologin d'un user sur Gnome
- Firefox se charge à l'ouverture de session du user, propose de rétablir les fenètres d'avant
- je restaure les fenètres Firefox, qui rechargent 3 vidéos Youtube différentes
- les fenêtres Firefox se chargent, puis jouent chacunes une pub puis de la vidéo...
- je passe une des trois vidéos en full screen
-> écran noir, PC bloqué, aucun message nul part

PC bloqué: souris figée, clavier sans effet, même SysReq sans effet. Le réseau est aussi mort, ma session SSH sur la boite tombe.

Je suppose qu'au moment d'agrandir la vidéo (rafraichissement de tout l'écran, appel à l'accélération), quelque chose va vite baver en RAM, où il ne le faudrait pas.
VINDICATORs wrote:C'est tout de même étonnant ce genre de plantage au bout d'un moment sans rien faire de particulier.
La courte et banale procédure que j'ai décrite juste plus haut tue le PC sur le champ lorsque je boote sur ce kernel de la distri, dont le pilote graphique Intel date de juillet dernier:
# uname -a
Linux ** 4.3.5-300.fc23.x86_64+debug #1 SMP Mon Feb 1 03:02:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
J'espérais pouvoir tirer plus (panic + crash dump) de ce kernel debug. Mais rien ne se passe. Le PC se bloque totalement, c'est tout. Et je me demande comment faire pour qu'il finisse par afficher quelque chose au sujet de ce crash.


Je viens de rebooter, avec le kernel Intel et leur pilote graphique, dans une version de janvier. Je peux sans problème agrandir (full screen) puis réduire l'une ou l'autre des vidéos Youtube, recommencer, le PC ne freeze pas. Vu d'ici, la différence est flagrante, avec ce kernel et pilote, tout va mieux:
# uname -a
Linux *** 4.5.0-rc2.intel-10805-g4d509d9-dirty #4 SMP Sat Feb 6 23:53:23 CET 2016 x86_64 x86_64 x86_64 GNU/Linux

Au journal, du crash d'avant, avec 4.3.5-300.fc23.x86_64+debug, rien de spécial:
[root@***~]# journalctl -b -1 |tail -25
Feb 09 16:56:34 ***systemd[1]: Startup finished in 3.178s (kernel) + 5.005s (initrd) + 28.922s (userspace) = 1min 1.473s.
Feb 09 16:56:34 ***audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-update-utmp-runlevel comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 09 16:56:34 ***audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-update-utmp-runlevel comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 09 16:56:36 ***firefox.desktop[2867]: *************************
Feb 09 16:56:36 ***firefox.desktop[2867]: A coding exception was thrown and uncaught in a Task.
Feb 09 16:56:36 ***firefox.desktop[2867]: Full message: TypeError: this.Paths is null
Feb 09 16:56:36 ***firefox.desktop[2867]: Full stack: Agent.write@resource:///modules/sessionstore/SessionWorker.js:196:9
Feb 09 16:56:36 ***firefox.desktop[2867]: worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
Feb 09 16:56:36 ***firefox.desktop[2867]: anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
Feb 09 16:56:36 ***firefox.desktop[2867]: @resource:///modules/sessionstore/SessionWorker.js:30:41
Feb 09 16:56:36 ***firefox.desktop[2867]: *************************
Feb 09 16:56:36 ***firefox.desktop[2867]: console.error:
Feb 09 16:56:36 ***firefox.desktop[2867]: Could not write session state file
Feb 09 16:56:36 ***firefox.desktop[2867]: Message: TypeError: this.Paths is null
Feb 09 16:56:36 ***firefox.desktop[2867]: Stack:
Feb 09 16:56:36 ***firefox.desktop[2867]: Agent.write@resource:///modules/sessionstore/SessionWorker.js:196:9
Feb 09 16:56:36 ***firefox.desktop[2867]: worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
Feb 09 16:56:36 ***firefox.desktop[2867]: anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
Feb 09 16:56:36 ***firefox.desktop[2867]: @resource:///modules/sessionstore/SessionWorker.js:30:41
Feb 09 16:56:36 ***firefox.desktop[2867]: Agent.write@resource:///modules/sessionstore/SessionWorker.js:196:9
Feb 09 16:56:36 ***firefox.desktop[2867]: worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
Feb 09 16:56:36 ***firefox.desktop[2867]: anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
Feb 09 16:56:36 ***firefox.desktop[2867]: @resource:///modules/sessionstore/SessionWorker.js:30:41
Feb 09 16:56:55 ***audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 09 16:56:59 ***audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
J'ai réussi à faire planter 4.5.0-rc2.intel-10805-g4d509d9-dirty aussi, pareil. Il fallait insister, agrandir et réduire plusieurs fois des vidéos. Ca ne m'arrange pas, je le supposais plus stable 🙂

4.3.5-300.fc23.x86_64 plante au bout de 30 minutes à 3 heures. Pour le moment, je peux agrandir et fermer des fenêtres sans que ça freeze.

Mais tant mieux si ces kernels plantent maintenant uassi vite ou facilement. Je voudrais maintenant savoir pourquoi ça bloque, que ces kernels affichent quelque chose ou dumpent un core lorsque ça bloque. Et pour le moment, je n'ai pas trouvé de solution.
Est ce que tu as testé la version xorg de Gnome (si tu l'utilise)? si cela ce trouve c'est un souci avec wayland par défaut qui est encore perfectible.

Normalement en "su -" tu dois avoir accès aux fichiers de logs complet.

Perso :
 ~]# cat /var/log/
anaconda/                 dnf.rpm.log-20160121      messages-20160131
audit/                    dnf.rpm.log-20160125      messages-20160208
boot.log                  dnf.rpm.log-20160131      pluto/
btmp                      dnf.rpm.log-20160208      ppp/
btmp-20160201             firewalld                 README
chrony/                   glusterfs/                samba/
cluster/                  grubby                    sddm.log
cron                      hawkey.log                secure
cron-20160121             hawkey.log-20160121       secure-20160121
cron-20160125             hawkey.log-20160125       secure-20160125
cron-20160131             hawkey.log-20160131       secure-20160131
cron-20160208             hawkey.log-20160208       secure-20160208
cups/                     journal/                  spooler
dnf.librepo.log           lastlog                   spooler-20160121
dnf.librepo.log-20160121  libvirt/                  spooler-20160125
dnf.librepo.log-20160125  maillog                   spooler-20160131
dnf.librepo.log-20160131  maillog-20160121          spooler-20160208
dnf.librepo.log-20160208  maillog-20160125          sssd/
dnf.log                   maillog-20160131          tallylog
dnf.log-20160121          maillog-20160208          wpa_supplicant.log
dnf.log-20160125          mariadb/                  wtmp
dnf.log-20160131          messages                  Xorg.0.log
dnf.log-20160208          messages-20160121         Xorg.0.log.old
dnf.rpm.log               messages-20160125         Xorg.9.log
Tout doit être dans "messages", voir dans "messages-datesdufichierdelogprécédent".
VINDICATORs wrote:Est ce que tu as testé la version xorg de Gnome (si tu l'utilise)? si cela ce trouve c'est un souci avec wayland par défaut qui est encore perfectible.

Normalement en "su -" tu dois avoir accès aux fichiers de logs complet.
J'ai la version Gnome livrée Fedora 23. Et en super user, les logs n'existent plus, tout a été transféré dans le journal (journalctl). Ca a changé vers Fedora 20:
https://ask.fedoraproject.org/en/question/9299/sticky-how-do-i-view-logs-on-fedora/

Il existe bien des solutions pour générer encore des /var/log/messages(.X). Mais ce serait redondant.

Chez moi, ça ressemble à ceci, ça se consulte avec "journalctl":
# journalctl -b | head -1
-- Logs begin at Fri 2016-02-05 19:05:23 CET, end at Tue 2016-02-09 20:11:54 CET. --


# ls /var/log
anaconda  cups                      firewalld            iptraf-ng  samba
audit     dnf.librepo.log           gdm                  journal    speech-dispatcher
BackupPC  dnf.librepo.log-20160207  glusterfs            lastlog    sssd
boot.log  dnf.log                   grubby               libvirt    tallylog
btmp      dnf.log-20160207          hawkey.log           pluto      wpa_supplicant.log
chrony    dnf.rpm.log               hawkey.log-20160207  ppp        wtmp
cluster   dnf.rpm.log-20160207      httpd                README     yum.log


# ls /var/log/journal/36b3cddf346b4ddbbd12b90b60f57e6a
system@00052b108d598209-017815239c993fc2.journal~
system@00052b10ff7cabb9-16e25dfcb10b40c4.journal~
system@00052b19fbbe39ac-3e24bb91f43a2c51.journal~
system@00052b1fe67a2b4c-9d931d13458e2617.journal~
system@00052b20296974bd-f22ea3d6658de3cf.journal~
system@00052b33a318ebf4-0beaf8e5aa67dbd0.journal~
system@00052b33daa43dd1-94e1b890048969fe.journal~
system@00052b386b7fcd93-905fc3f46ab7a98a.journal~
system@00052b387ae1b1ed-1a353b8c5654a7e3.journal~
system@00052b38ab577319-e282eb6fdadafd6c.journal~
system@00052b3b04fb4870-aeb293d88dcb0f20.journal~
system@00052b4ced330528-cb3d19580a822c90.journal~
system@00052b566b67da27-4ab7171e488c2868.journal~
system@00052b56956a35d7-22b1ad4b9657b9b1.journal~
system@00052b585b1fcb1f-10afa835e224aac9.journal~
system@00052b5954de63e1-89bc8933b71b9216.journal~
system@00052b599e28ba1c-6973e5cc3782d7ac.journal~
system@c70102ecf925486498b56bf92aed66ef-0000000000000001-00052b20ffb84fbf.journal
system@c70102ecf925486498b56bf92aed66ef-0000000000014d41-00052b27d0db3e66.journal
system.journal
user-1000@00052b10f9784530-cd83e146b6b64110.journal~
user-1000@cec7890ff32d4cf18f690da324a8c703-000000000000090c-00052b10f97877c4.journal
user-1000@cec7890ff32d4cf18f690da324a8c703-0000000000014d42-00052b27d0db4268.journal
user-1000.journal
user-1001@f803430e3cb6426da45b789b39ab6fc8-0000000000002f22-00052b1c0a113e71.journal
user-1001.journal
user-1002@00052b387b30ea20-c992da7434547fe0.journal~
user-1002@00052b38aba8d0a8-8e51f0ceb04c5ec8.journal~
user-1002@00052b3b0542c7bb-c09f3c8023ca2694.journal~
user-1002@00052b4ced8240c1-fbb8b26a2995b9bc.journal~
user-1002@00052b55fd7704c1-056274203b5593a0.journal~
user-1002@00052b5695ac62a1-c27f9accc1acae24.journal~
user-1002@00052b585b6143c0-3af6e2d668414495.journal~
user-1002@00052b5955299700-cbe0eff07e75b1ed.journal~
user-1002.journal


# file /var/log/journal/36b3cddf346b4ddbbd12b90b60f57e6a/system@00052b108d598209-017815239c993fc2.journal~
/var/log/journal/36b3cddf346b4ddbbd12b90b60f57e6a/system@00052b108d598209-017815239c993fc2.journal~: Journal file, offline, compressed

VINDICATORs wrote:...
Normalement en "su -" tu dois avoir accès aux fichiers de logs complet.

Perso :
 ~]# cat /var/log/
anaconda/                 dnf.rpm.log-20160121      messages-20160131
audit/                    dnf.rpm.log-20160125      messages-20160208
boot.log                  dnf.rpm.log-20160131      pluto/
btmp                      dnf.rpm.log-20160208      ppp/
btmp-20160201             firewalld                 README
chrony/                   glusterfs/                samba/
cluster/                  grubby                    sddm.log
cron                      hawkey.log                secure
cron-20160121             hawkey.log-20160121       secure-20160121
cron-20160125             hawkey.log-20160125       secure-20160125
cron-20160131             hawkey.log-20160131       secure-20160131
cron-20160208             hawkey.log-20160208       secure-20160208
cups/                     journal/                  spooler
dnf.librepo.log           lastlog                   spooler-20160121
dnf.librepo.log-20160121  libvirt/                  spooler-20160125
dnf.librepo.log-20160125  maillog                   spooler-20160131
dnf.librepo.log-20160131  maillog-20160121          spooler-20160208
dnf.librepo.log-20160208  maillog-20160125          sssd/
dnf.log                   maillog-20160131          tallylog
dnf.log-20160121          maillog-20160208          wpa_supplicant.log
dnf.log-20160125          mariadb/                  wtmp
dnf.log-20160131          messages                  Xorg.0.log
dnf.log-20160208          messages-20160121         Xorg.0.log.old
dnf.rpm.log               messages-20160125         Xorg.9.log
Tout doit être dans "messages", voir dans "messages-datesdufichierdelogprécédent".
@VINDICATORs :
Chez moi :
[root@localhost ~]# cat /var/log/
cat: /var/log/: est un dossier
[root@localhost ~]# ls -p /var/log/
anaconda/                 dnf.rpm.log-20160124  ppp/
audit/                    dnf.rpm.log-20160131  README
boot.log                  dnf.rpm.log-20160208  samba/
btmp                      firewalld             sddm.log
btmp-20160201             grubby                secure
chrony/                   hawkey.log            secure-20160118
ConsoleKit/               hawkey.log-20160118   secure-20160124
cron                      hawkey.log-20160124   secure-20160131
cron-20160118             hawkey.log-20160131   secure-20160208
cron-20160124             hawkey.log-20160208   spooler
cron-20160131             java_install.log      spooler-20160118
cron-20160208             journal/              spooler-20160124
cups/                     lastlog               spooler-20160131
dnf.librepo.log           maillog               spooler-20160208
dnf.librepo.log-20160118  maillog-20160118      sssd/
dnf.librepo.log-20160124  maillog-20160124      tallylog
dnf.librepo.log-20160131  maillog-20160131      vbox/
dnf.librepo.log-20160208  maillog-20160208      wpa_supplicant.log
dnf.log                   mariadb/              wtmp
dnf.log-20160118          messages              Xorg.0.log
dnf.log-20160124          messages-20160118     Xorg.0.log.old
dnf.log-20160131          messages-20160124     Xorg.9.log
dnf.log-20160208          messages-20160131     yum.log
dnf.rpm.log               messages-20160208     yum.log-20160101
dnf.rpm.log-20160118      pluto/

Fifi wrote:@VINDICATORs :
Chez moi :
[root@localhost ~]# cat /var/log/
cat: /var/log/: est un dossier
[root@localhost ~]# ls -p /var/log/
anaconda/                 dnf.rpm.log-20160124  ...
Euh... je viens de jeter 40Mo de logs, de plusieurs jours, parce que de toute façon je n'y voyais rien d'intéressant.

Par le passé, j'avais tout dans des fichiers. J'ai une debian ou c'est encore dans des fichiers séparés (je préfère, j'ai pas trop l'habitude du journal commun).

Ici, sur cette fc23, tout est stocké dans le journal. L'équivalent syslog, les logs du kernel, de dnf, etc, tout devrait y être:
# journalctl --list-boot
-1 6caa320eb3d9457fa80e3fe9906135a0 Tue 2016-02-09 22:00:01 CET—Wed 2016-02-10 00:21:35 CET
 0 db745b1da6574781bdaa1df3a6205166 Wed 2016-02-10 01:22:06 CET—Wed 2016-02-10 00:38:57 CET

# journalctl --system -b | tail
Feb 10 00:32:32 *** audit: NETFILTER_CFG table=mangle family=10 entries=0
Feb 10 00:32:32 *** audit: NETFILTER_CFG table=raw family=10 entries=0
Feb 10 00:32:32 *** audit: NETFILTER_CFG table=nat family=10 entries=0
Feb 10 00:32:32 *** audit: NETFILTER_CFG table=security family=10 entries=0
Feb 10 00:33:42 *** kernel: perf interrupt took too long (2556 > 2500), lowering ...

# journalctl _COMM=systemd |tail
Feb 10 00:24:03 *** systemd[1]: Started Update UTMP about System Runlevel Changes.
Feb 10 00:24:03 *** systemd[1]: Startup finished in 2.542s (kernel) + 2.674s (initrd) + 1min 54.449s (userspace) = 2min 22.977s.
Feb 10 00:26:07 *** systemd[1]: Stopping Crash recovery kernel arming...
Feb 10 00:26:07 *** systemd[1]: Stopped Crash recovery kernel arming.
Feb 10 00:26:12 *** systemd[1]: Starting Crash recovery kernel arming...
Feb 10 00:26:15 *** systemd[1]: Started Crash recovery kernel arming.
Feb 10 00:32:14 *** systemd[1]: Starting dnf makecache...
Feb 10 00:32:15 *** systemd[1]: Started dnf makecache.
Je viens de le faire crasher à répétition. Au passage, lors d'un reboot, j'ai remarqué un message "...journal corrupted..." Dans ces conditions, et s'il fait le ménage dans le journal lorsqu'il a planté, difficile de voir quelque chose dans les logs, après redémarrage. Le journal semble bien avoir du mal à encaisser les crashs à répétition:
# journalctl --list-boot
Failed to determine boots: No data available
Pas de journal, mais ce n'est plus un problème (théoriquement). Car avec un crash dump, on peut avoir une idée de la cause du crash, le dmesg est dumpé (quand ça fonctionne):
[   54.953556] sysrq: SysRq : Trigger a crash
[   54.953617] BUG: unable to handle kernel NULL pointer dereference at           (null)
[   54.953764] IP: [<ffffffff81488816>] sysrq_handle_crash+0x16/0x20
[   54.953873] PGD 0
[   54.953918] Oops: 0002 [#1] SMP
Quelque chose d'autre coince encore. Car j'essaye toujours de le faire parler plus.

Je suis maintenant de retour sur un kernel 4.3.5, une version de debug, plus bavarde que la normale, même plus bavarde que le kernel fc23 de debug. Une version qui est supposée générer un état panic sur des états anormaux supplémentaires comparé à un kernel normal. Le kernel de debug ne ralentit pas particulièrement pas le PC. Et kdump est configuré.

Problème, maintenant: quand le PC se bloque comme d'habitude, il reste toujours totalement bloqué. Je dois certainement revoir les options du kernel, les anomalies qu'il peut détecter.


Kdump a fini par fonctionner. "# echo c > /proc/sysrq-trigger" en shell, et hop, le Linux génère un core dump... En théorie, sur des états anormaux, le Linux devrait de lui même générer un dump. Dans la limite ce ce qui est configuré dans le kernel utilisé.
# systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2016-02-10 03:28:56 CET; 6min ago
  Process: 931 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 931 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/kdump.service

Feb 10 03:28:53 *** systemd[1]: Starting Crash recovery kernel arming...
Feb 10 03:28:56 *** kdumpctl[931]: kexec: loaded kdump kernel
Feb 10 03:28:56 *** kdumpctl[931]: Starting kdump: [OK]
Feb 10 03:28:56 *** systemd[1]: Started Crash recovery kernel arming.
Avec le dump, il y a un fichier texte. Au reboot du PC, une session Gnome s'est ouverte. Puis j'ai provoqué un crash:
# echo c > /proc/sysrq-trigger
C'est vu plus loin, par la netconsole, et bien reçu par le kernel, qui part ensuite en dump:
[  412.126152] Call Trace:
[  412.132146]  [<ffffffff8148901a>] __handle_sysrq+0xea/0x140
[  412.138161]  [<ffffffff8148949f>] write_sysrq_trigger+0x2f/0x40
[  412.144143]  [<ffffffff8128d512>] proc_reg_write+0x42/0x70
[  412.150090]  [<ffffffff81221007>] __vfs_write+0x37/0x110
X est quitté, puis à la console, on voit que le dump est réalisé. On trouve ensuite les dumps sur le disque (sysrq_handle_crash+0x16/0x20):
# ls
127.0.0.1-2016-02-10-02:49:23  127.0.0.1-2016-02-10-03:04:11


# ls -al
total 78852
drwxr-xr-x   2 root root     4096 Feb 10 03:05 .
drwxr-xr-x. 12 root root     4096 Feb 10 03:28 ..
-rw-------   1 root root 80661578 Feb 10 03:05 vmcore
-rw-r--r--   1 root root    71961 Feb 10 03:05 vmcore-dmesg.txt


# head 127.0.0.1-2016-02-10-03:04:11/vmcore-dmesg.txt
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.3.5-own (***@***) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Tue Feb 9 23:49:29 CET 2016
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.3.5-own root=/dev/mapper/fedora_***-root ro rd.lvm.lv=fedora_***/root rhgb quiet crashkernel=256M
[    0.000000] x86/fpu: Legacy x87 FPU detected.
[    0.000000] x86/fpu: Using 'lazy' FPU context switches.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000003efff] usable
[    0.000000] BIOS-e820: [mem 0x000000000003f000-0x000000000003ffff] ACPI NVS


# tail 127.0.0.1-2016-02-10-03:04:11/vmcore-dmesg.txt -n 25
[   81.966312] RBP: ffff8800b6f33dd0 R08: 0000000000000002 R09: 0000000000000397
[   81.966421] R10: 0000000000000001 R11: 0000000000000397 R12: 0000000000000008
[   81.966528] R13: 0000000000000000 R14: ffffffff81cc2160 R15: 0000000000000000
[   81.966639] FS:  00007fea2f8d1700(0000) GS:ffff88023fc80000(0000) knlGS:0000000000000000
[   81.966761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   81.966850] CR2: 0000000000000000 CR3: 000000023571e000 CR4: 00000000001006e0
[   81.966956] Stack:
[   81.966993]  ffff8800b6f33e00 ffffffff8148901a 0000000000000002 fffffffffffffffb
[   81.967132]  ffff8800b6f33f18 0000000000000002 ffff8800b6f33e18 ffffffff8148949f
[   81.967272]  ffff880235c2a6c0 ffff8800b6f33e38 ffffffff8128d512 ffff88009981d500
[   81.967412] Call Trace:
[   81.967460]  [<ffffffff8148901a>] __handle_sysrq+0xea/0x140
[   81.967553]  [<ffffffff8148949f>] write_sysrq_trigger+0x2f/0x40
[   81.967649]  [<ffffffff8128d512>] proc_reg_write+0x42/0x70
[   81.967741]  [<ffffffff81221007>] __vfs_write+0x37/0x110
[   81.967829]  [<ffffffff81202013>] ? kmem_cache_alloc+0x193/0x210
[   81.967928]  [<ffffffff8123e3e3>] ? __fd_install+0x33/0xe0
[   81.968019]  [<ffffffff810e7c34>] ? percpu_down_read+0x14/0x60
[   81.968114]  [<ffffffff81221716>] vfs_write+0xa6/0x1a0
[   81.968198]  [<ffffffff812223d5>] SyS_write+0x55/0xc0
[   81.968282]  [<ffffffff8177e12e>] entry_SYSCALL_64_fastpath+0x12/0x71
[   81.968382] Code: ef e8 1f f8 ff ff eb db 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 c4 71 7b 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 c7 05 40 aa 7c
[   81.969112] RIP  [<ffffffff81488816>] sysrq_handle_crash+0x16/0x20
[   81.969221]  RSP <ffff8800b6f33dd0>
[   81.969278] CR2: 0000000000000000
Pour retrouver le syslog, tu peux me retourner le résultat de la commande suivant :
systemctl status syslog
syslog? Je crois que ça fonctionne avec syslog-ng, qui lui même va extraire ses données du journal pour générer ensite les logs plus communs.

Sinon, j'ai vu qu'il devait aussi exister une appli graphique qui affiche directement les données du journal sous X:
https://fedoramagazine.org/simply-view-system-logs-in-fedora-21-workstation/

syslog-ng, j'ai pas voulu mettre le nez là dedans...
# systemctl status syslog
● syslog.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

# dnf search syslog-ng
Last metadata expiration check performed 5:11:17 ago on Wed Feb 10 04:40:07 2016.
=========================================== N/S Matched: syslog-ng ===========================================
syslog-ng.i686 : Next-generation syslog server
syslog-ng.x86_64 : Next-generation syslog server
syslog-ng-json.x86_64 : json support for syslog-ng
syslog-ng-smtp.x86_64 : smtp support for syslog-ng
syslog-ng-geoip.x86_64 : geoip support for syslog-ng
syslog-ng-redis.x86_64 : redis support for syslog-ng
syslog-ng-libdbi.x86_64 : libdbi support for syslog-ng
syslog-ng-devel.i686 : Development files for syslog-ng
syslog-ng-devel.x86_64 : Development files for syslog-ng
syslog-ng-mongodb.x86_64 : mongodb support for syslog-ng
syslog-ng-riemann.x86_64 : riemann support for syslog-ng
eventlog.i686 : Syslog-ng v2/v3 support library
eventlog.x86_64 : Syslog-ng v2/v3 support library
eventlog-static.i686 : Syslog-ng v2/v3 support static library files
eventlog-static.x86_64 : Syslog-ng v2/v3 support static library files
eventlog-devel.i686 : Syslog-ng v2/v3 support library development files
eventlog-devel.x86_64 : Syslog-ng v2/v3 support library development files
syslog? Je veux bien. Puisque après un crash de ce genre (freeze complet), les données du journal lui-même peuvent être corrompues. Comment ça se met en route?

https://wiki.archlinux.org/index.php/systemd#Journald_in_conjunction_with_syslog "Compatibility with a classic, non-journald aware syslog implementation can be provided by letting systemd forward all messages via the socket /run/systemd/journal/syslog. To make the syslog daemon work with the journal, it has to bind to this socket instead of /dev/log (official announcement). http://lwn.net/Articles/474968/

As of systemd 216 the default journald.conf for forwarding to the socket was changed to ForwardToSyslog=no to avoid system overhead, because rsyslog or syslog-ng (since 3.6) pull the messages from the journal by itself. "
Installe rsyslog et lance :
systemctl enable syslog.service
si ce n'est déjà fait.
VINDICATORs wrote:Installe rsyslog et lance :
systemctl enable syslog.service
si ce n'est déjà fait.
Je vais l'ajouter ce soir. Si le journal se corrompt ou purge tout ou partie après crash, ce syslog retiendra peut-être quelque chose d'intéressant.

Sinon, j'ai repéré ce truc qui pourrai un jour être utile, à d'autres fins: http://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu Why does kworker hog your CPU? To find out why a kworker is wasting your CPU, you can create CPU backtraces: watch your processor load (with top or something) and in moments of high load through kworker, execute echo l > /proc/sysrq-trigger to create a backtrace
Vérifie aussi ton disque, ça ne mange pas de pain.
VINDICATORs wrote:Vérifie aussi ton disque, ça ne mange pas de pain.
C'est le risque avec tous ces crashs ou freezes. Je m'en remets aux fsck qu'il fait tout seul au boot. Ca peut détruite les systèmes de fichier, selon la nature du bug. Le cas échéant, je réinstallerais.

J'ai réussi à obtenir un dump, du dmesg. Il a planté, et j'ai fini par trouver l'astuce pour en générer un. Il n'y a rien du tout dans les logs dmesg.

Je peux donc faire planter autant que je veux chacun de ces kernels, du fait de ces problèmes de vidéo, et manifestement aussi générer des dumps. Pouvoir reproduire et arriver à tracer les problèmes, c'est essentiel à leur résolution.
....
[   15.618315] virbr0: port 1(virbr0-nic) entered listening state
[   15.618348] virbr0: port 1(virbr0-nic) entered listening state
[   15.688532] virbr0: port 1(virbr0-nic) entered disabled state
[   20.113691] Adjusting tsc more than 11% (3669856 vs 4655677)
[   98.408997] sysrq: SysRq : Keyboard mode set to system default
[  105.711176] sysrq: SysRq : Keyboard mode set to system default
[  570.518101] perf interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[  588.742671] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
[ 1243.970783] usb 1-4.2: USB disconnect, device number 5
[ 1276.586726] perf interrupt took too long (5012 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 6476.243690] perf interrupt took too long (11570 > 9615), lowering kernel.perf_event_max_sample_rate to 1300
0
[34792.558816] sysrq: SysRq : Trigger a crash
[34792.558869] BUG: unable to handle kernel NULL pointer dereference at           (null)
[34792.558956] IP: [<ffffffff81488816>] sysrq_handle_crash+0x16/0x20
[34792.559019] PGD 0
[34792.559045] Oops: 0002 [#1] SMP
L'astuce était simple. J'essayais de détacher le clavier de X après le freeze de X. Ce qui n'allait pas. J'ai donc détaché le clavier avant le freeze de X. De tout façon, X freeze tout seul, sans actions au clavier.

Ce matin, Alt+SysReq+r bien reçu par le kernel: [ 98.408997] sysrq: SysRq : Keyboard mode set to system default (détaché de X, rattaché à nouveau à la console)

Ce soir, alors que le PC avait planté, et car le clavier était déjà détaché par les actions précédentes, j'ai pu provoquer le dump avec Alt+SysRed+c ce qui a provoqué [34792.558816] sysrq: SysRq : Trigger a crash

Entre [ 6476.243690] et [34792.558816] rien du tout dans le dmesg, juste "0" sorti de je ne sais où et quand. Je vais recommencer. J'ai peut-être fait une connerie 🙂

Lui aussi semble avoir fait une connerie. J'ai 8Go de RAM. Il a trouvé et dumpé 11Go de RAM?
# ls -al
total 109332
drwxr-xr-x   2 root root      4096 Feb 10 20:03 .
drwxr-xr-x. 14 root root      4096 Feb 10 19:20 ..
-rw-------   1 root root 111873588 Feb 10 19:20 vmcore
-rw-r--r--   1 root root     73270 Feb 10 19:20 vmcore-dmesg.txt
J'ai pas de swap, juste de la RAM, 8Go:
top - 20:16:25 up 55 min,  3 users,  load average: 6.18, 4.09, 1.87
Tasks: 214 total,   6 running, 208 sleeping,   0 stopped,   0 zombie
%Cpu(s): 56.1 us, 18.5 sy,  0.0 ni, 16.9 id,  7.8 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem :  7796172 total,  5307428 free,  1083348 used,  1405396 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  6150740 avail Mem

PS: J'ai ajouté rsyslog. Pour le moment, il n'y a rien dans /var/log/message. C'est à configurer?
Installed:
  libestr.x86_64 0.1.9-5.fc23     liblogging-stdlog.x86_64 1.0.4-5.fc23     rsyslog.x86_64 8.10.0-1.fc23

Complete!

# systemctl enable rsyslog
# systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/

# ls /var/log
anaconda  cups                      firewalld            iptraf-ng  ppp                tallylog
audit     dnf.librepo.log           gdm                  journal    README             wpa_supplicant.log
BackupPC  dnf.librepo.log-20160207  glusterfs            lastlog    samba              wtmp
boot.log  dnf.log                   grubby               libvirt    secure             yum.log
btmp      dnf.log-20160207          hawkey.log           maillog    speech-dispatcher
chrony    dnf.rpm.log               hawkey.log-20160207  messages   spooler
cluster   dnf.rpm.log-20160207      httpd                pluto      sssd

# cat /var/log/messages
#

# journalctl -b | tail -n 4
Feb 10 20:20:17 *** kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 10 20:20:17 *** kernel: CR2: 00007f45c8089000 CR3: 0000000231f20000 CR4: 00000000001006e0
Feb 10 20:20:17 *** kernel:
Feb 10 20:21:34 *** org.gnome.evolution.dataserver.Sources5[1948]: ** (evolution-source-registry:2751): WARNING **: secret_service_search_sync: must specify at least one attribute to match
# cat /var/log/messages
#
Des extraits de la conf existante, ça semble être bon, sauf probablement des options:
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
...
# Log cron stuff
cron.*                                                  /var/log/cron

# cat /etc/sysconfig/rsyslog
# Options for rsyslogd
# Syslogd options are deprecated since rsyslog v3.
# If you want to use them, switch to compatibility mode 2 by "-c 2"
# See rsyslogd(8) for more details
SYSLOGD_OPTIONS=""