justice.cloppy.net

L'assistance éducative ou ce qui s'y apparente

11.02.16 03:06, 4415 vues

Je continue à jouer avec cette même boite, une Fedora 23, sur la quelle je fais défiler des kernels et des pilotes i915 pour une carte type Intel Z36xxx/Z37xxx Series Graphics (un Shuttle XS35V4, un Celeron). Avec l'accélération graphique active, pour la 2D et la vidéo. La Fedora reste fiable et stable, malgré tout ce que je lui inflige depuis quelques jours.

J'ai finalement trouvé des façons assez simples pour faire très vite planter (freeze ou hang) les kernels 4.3.5, le 4.5.0rc2 et même le kernel drm/intel que j'ai récupéré récemment via 01.org. Des kernels standards, standard de debug, ainsi que des kernels un peu bidouillés. Tous ont leurs spécificités mais chacun d'entre eux fini par se vautrer très vite, trop vite.

Je ne fais rien de plus que de démarrer le PC, d'ouvrir une session Gnome, puis je clique ensuite quelques fois pour ouvrir des vidéos Youtube avec Firefox. Selon le kernel, son humeur ou la mienne, et selon les clics à la souris, le PC plante au bout de 5 minutes, voire au bout de 3 heures. Avec Chrome et Netflix, ça plante parfois plus vite ; parfois seulement.

On m'a informé que pour ce petit barbone ou ces cartes de type Intel G45 & HD Graphics, il existe aussi libva-intel-driver. Il me semble l'avoir déjà utilisé par le passé ; je n'ai pas encore pris le temps de le stresser également. Je reste occupé par Linux, qui restait aphone, totalement bloqué après un tel freeze ou hang. Rien dans les logs, rien à l'écran, figé, rien à la netconsole, plus de réseau, juste un grand silence, pas un mot. Un Linux pas plus bavard que des ministères ou qu'un troupeau d'avocats de Metz très sérieusement provoqués mais qui auraient décidé de ne jamais vous répondre...

J'ai fini par comprendre enfin comment utiliser des claviers, la touche Alt et SysReq, kdump, par générer ensuite des vmcores, dumps que je commence à lire avec crash. L'étape d'après consistera à approfondir un peu mieux les options de debug du kernel, les sources, gdb et le contenu de /sys/kernel/debug/. C'est vaste... Et bizarre, ce que j'ai pu voir jusqu'à présent. Un PC manifestement au repos lorsqu'il est planté, avec rien du tout dans les queues du kernel, juste Firefox ?

      KERNEL: /mnt/kernels/linux-4.3.5/vmlinux
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 4
        DATE: Wed Feb 10 19:20:39 2016
      UPTIME: 09:38:43
LOAD AVERAGE: 0.25, 0.25, 0.23
       TASKS: 433
    NODENAME: ***
     RELEASE: 4.3.5-own
     VERSION: #1 SMP Tue Feb 9 23:49:29 CET 2016
     MACHINE: x86_64  (1996 Mhz)
      MEMORY: 7.9 GB
       PANIC: "sysrq: SysRq : Trigger a crash"
         PID: 2913
     COMMAND: "firefox"
        TASK: ffff8800b7bd0000  [THREAD_INFO: ffff8802322e8000]
         CPU: 0
       STATE: TASK_RUNNING (SYSRQ)
crash> runq
CPU 0 RUNQUEUE: ffff88023fc16c80
  CURRENT: PID: 2913   TASK: ffff8800b7bd0000  COMMAND: "firefox"
  RT PRIO_ARRAY: ffff88023fc16e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fc16d20
     [no tasks queued]

CPU 1 RUNQUEUE: ffff88023fc96c80
  CURRENT: PID: 0      TASK: ffff880236270000  COMMAND: "swapper/1"
  RT PRIO_ARRAY: ffff88023fc96e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fc96d20
     [no tasks queued]

CPU 2 RUNQUEUE: ffff88023fd16c80
  CURRENT: PID: 0      TASK: ffff880236271c00  COMMAND: "swapper/2"
  RT PRIO_ARRAY: ffff88023fd16e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fd16d20
     [no tasks queued]

CPU 3 RUNQUEUE: ffff88023fd96c80
  CURRENT: PID: 0      TASK: ffff880236273800  COMMAND: "swapper/3"
  RT PRIO_ARRAY: ffff88023fd96e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fd96d20
     [no tasks queued]

Un crash dump du même PC bien éveillé et normalement chargé produit un résultat assez différent :

crash> runq
CPU 0 RUNQUEUE: ffff88023fc16c80
  CURRENT: PID: 2549   TASK: ffff880231bf0000  COMMAND: "gnome-shell"
  RT PRIO_ARRAY: ffff88023fc16e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fc16d20
     [130] PID: 5012   TASK: ffff8801eb098000  COMMAND: "stress"
     [130] PID: 5019   TASK: ffff8801b8691c00  COMMAND: "stress"

CPU 1 RUNQUEUE: ffff88023fc96c80
  CURRENT: PID: 5014   TASK: ffff8801dae00000  COMMAND: "stress"
  RT PRIO_ARRAY: ffff88023fc96e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fc96d20
     [130] PID: 5016   TASK: ffff8801dae03800  COMMAND: "stress"
     [130] PID: 5011   TASK: ffff8802316d5400  COMMAND: "stress"
     [130] PID: 5017   TASK: ffff8801dae05400  COMMAND: "stress"
     [130] PID: 5008   TASK: ffff880205f75400  COMMAND: "stress"
     [130] PID: 5018   TASK: ffff8801b8690000  COMMAND: "stress"

CPU 2 RUNQUEUE: ffff88023fd16c80
  CURRENT: PID: 5015   TASK: ffff8801dae01c00  COMMAND: "stress"
  RT PRIO_ARRAY: ffff88023fd16e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fd16d20
     [130] PID: 5013   TASK: ffff8802316a1c00  COMMAND: "stress"
     [130] PID: 5009   TASK: ffff8800b640b800  COMMAND: "stress"

CPU 3 RUNQUEUE: ffff88023fd96c80
  CURRENT: PID: 1675   TASK: ffff8802315a1c00  COMMAND: "Xorg"
  RT PRIO_ARRAY: ffff88023fd96e30
     [no tasks queued]
  CFS RB_ROOT: ffff88023fd96d20
     [120] PID: 3033   TASK: ffff8800b7139c00  COMMAND: "Compositor"
     [120] PID: 2858   TASK: ffff880232121c00  COMMAND: "firefox"
     [130] PID: 5010   TASK: ffff8802312a5400  COMMAND: "stress"

Ce qui suit pourrait agacer Linus Torvald... Ce que j'ai publié n'a jamais plu à tout le monde :>>

Objet	What can a "freezed" X server status be, and a HowTo to get some kernel crash dumps
De	Bruno Kant
À	dri-devel@lists.freedesktop.org
Répondre à	bkant@cloppy.net
Date	Aujourd'hui 02:48
	Hello, A few days ago, someone on the list wrote he will configure netconsole to get some messages or debug data. But this will not work. When the box freezes, its network is dead also. I'm still busy with my video driver(s) and kernels. I'm now able to decently and repetitively "freeze" any of 4.3.5, 4.5.0rc2 kernels, the drm/intel (based on 4.5.0rc2) I cloned last week also. I am now also able to get debug traces. Reproductible issues and some traces can be helpfull to debug codes, so I share my findings, a quick HowTo. WARNING: "freezes" can kill your file systems. This procedure (reboot without sync) also, use at your own risks. Fedora and the kernels I'm using each time recovered mine, after many "freezes" or crashes and such reboots. I recall my hardware, which is Shuttle XSV35V4 (Celeron, BIOS XS35V400.400), the video is: # lspci -nnk \| egrep -iA3 "VGA" 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e) DeviceName: Onboard IGD Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:4019] Kernel driver in use: i915 I'm just booting on those different kernels, with either kernel debug options or not. Then I open a gnome session and play Youtube videos with Firefox. Sometime, for quicker crashes and dumps, I'm using also Chrome and Neflix. But Firefox and Youtube are enough. That's enough to kill the box, within hours and even within minutes. Play 3 videos streams/channels/playlists on two monitors, switch videos to full screen, then back to browser, and so on. This "freezes" the box, whatever the standard kernel is. It is almost repetitive, takes more or less time, some minutes, or couple of hours when videos just play, with acceleration+DRI active. It is what I get with this Shuttle XSV35V4. I never noticed any message related to the freezes in my syslog/journal. Neitheir did I on the PC screen, neither over SSH, nor over my netconsole. But I can now dump some nice debugs with following tools and steps. Set up SysReq, setup kdump, follow the common procedures. Check that you get your dumps. Here is a tuto for Fedora: https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes For the next steps, use two keyboards. I'm using a common Cherry USB keyboard and a Logitec wireless keyboard. I assume any pair of keyboards will do the job. Why two keyboad? One will interact with X, the other will interact with your kernel. Once in gnome, you will have two active keyboards. On the USB keyboard, press Alt+SysReq+r. Now the USB keyboard is detached from X, will interacts with the kernel (check this in your /var/log/messages or journalctl -f). Detach it immediatly after X/gnome and session startup. The keyboard canot be detached anymore later, once the box is "freezed". Keep now the USB keyboard for later. Or test if it works, press Alt+SysReq+c on your detached keyboard, check if you get your core dump... Use now your second keyboard and mouse to interact with X. Play videos with acceleration+DRI active in X. The box will die. Or maybe, play with your favorite game, and try this same process... When the box is dead, take your previously detached USB keyboard. Press there Alt+SysReq+c. X/gnome will shutdown, and the core gets dumped (the magic key "c"). With your dumped vmcore, you will get a text file corresponding to the dmesg content (kernel messages, from the boot untill the core dump): 127.0.0.1-2016-02-10-19:20:47]# ls -al total 109408 drwxr-xr-x 2 root root 4096 Feb 10 23:36 . drwxr-xr-x. 15 root root 4096 Feb 10 23:37 .. -rw------- 1 root root 111873588 Feb 10 19:20 vmcore -rw-r--r-- 1 root root 73270 Feb 10 19:20 vmcore-dmesg.txt If you used a debug kernel, you can open and read the vmcore content, check basic and more dumped data. The dmesg content, the processor runq, the ps list, and more at the time the dump was triggered. To read the vmcore data, you will need the path to vmlinux built with your debug kernel: # crash /mnt/kernels/linux-4.3.5/vmlinux vmcore For one "freeze", I have noticed that 3 CPU where idle and that only Firefox remained active on my box... That status I noticed is below. Why where almost all processes idle? According to the dumped ps list, processes where still alive, but the CPU queues where empty. I'll investigate this further. Best regards crash> runq CPU 0 RUNQUEUE: ffff88023fc16c80 CURRENT: PID: 2913 TASK: ffff8800b7bd0000 COMMAND: "firefox" RT PRIO_ARRAY: ffff88023fc16e30 [no tasks queued] CFS RB_ROOT: ffff88023fc16d20 [no tasks queued] CPU 1 RUNQUEUE: ffff88023fc96c80 CURRENT: PID: 0 TASK: ffff880236270000 COMMAND: "swapper/1" RT PRIO_ARRAY: ffff88023fc96e30 [no tasks queued] CFS RB_ROOT: ffff88023fc96d20 [no tasks queued] CPU 2 RUNQUEUE: ffff88023fd16c80 CURRENT: PID: 0 TASK: ffff880236271c00 COMMAND: "swapper/2" RT PRIO_ARRAY: ffff88023fd16e30 [no tasks queued] CFS RB_ROOT: ffff88023fd16d20 [no tasks queued] CPU 3 RUNQUEUE: ffff88023fd96c80 CURRENT: PID: 0 TASK: ffff880236273800 COMMAND: "swapper/3" RT PRIO_ARRAY: ffff88023fd96e30 [no tasks queued] CFS RB_ROOT: ffff88023fd96d20 [no tasks queued]