Archives pour: Février 2016
Juste Firefox ?
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] |
Up and running ?
Un up time de quelques 5 heures maintenant, avec 20160124, 3 vidéos et deux écrans... Croiser les doigts.
Edit... Manifestement, up, stable, sans freezes ou plantages aléatoires. Le Linux n'avait toujours pas crashé au bout de 14 heures, malgré deux écrans et trois vidéos sur ces écrans. Intel propose une sorte de 4.5.0-rc2 patchée, qui intègre leur dernier pilote i915 1.6.0 20160124. Depuis peu, j'ai la 4.5.0-rc2 standard up, j'y ai intégré ce dernier pilote Intel.
Le pilote xf86 version 2.99.917-544(-g8b8c9a3?) est ici : http://cgit.freedesktop.org/xorg/... video-intel. Pour d'autres précisions, les sources pour le kernel et le module i915, voir chez Intel... https://01.org/linuxgraphics/about « Before filing the bug, please try to reproduce your issue with the latest kernel. Use the latest drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel and build as instructed on our Build Guide », lit-on par là bas.
Edit... Soupirs... freezed au bout de 5 heures. C'est déjà mieux que 30 minutes. Mais moins bien qu'avec le kernel de chez Intel, qui était resté up 14 heures, jusqu'à ce que je reboote. Reste à comparer la 4.5.0-rc2 et la version 4.5.0-rc2 patchée par Intel, ce qui avait tourné 14 heures. Il doit encore y avoir autre chose que ces problèmes de vidéo.
Edit... up. 20 heures et toujours aucun crash ou freeze avec 4.5.0-rc2 et ce denier pilote i965 Intel. Avec Gnome, l'accélération dans X, Firefox et trois vidéos Youtube sur deux écrans. Je vais bannir Googgle Chrome, un truc particulier, et tout ira bien. 20 heures, c'est beaucoup, ça devrait rester stable si je n'abuse plus. Quand j'ai commencé à utiliser ce PC et la fc23, ça freezait au bout de 30 minutes à 1h30, même avec rien qu'une session Gnome ouverte.
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
top - 06:47:13 up 4:58, 3 users, load average: 6.79, 5.80, 5.45
Tasks: 228 total, 3 running, 225 sleeping, 0 stopped, 0 zombie
%Cpu(s): 57.8 us, 15.5 sy, 0.0 ni, 24.2 id, 1.9 wa, 0.0 hi, 0.6 si, 0.0 st
KiB Mem : 7927380 total, 3042136 free, 1451952 used, 3433292 buff/cache
[ 0.887631] [drm] Initialized i915 1.6.0 20160124 for 0000:00:02.0 on minor 0
[ 2.478319] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
$ grep -r "nr_swap_pages" --include="*.c"
drm-intel/mm/swapfile.c:atomic_long_t nr_swap_pages;
drm-intel/mm/swapfile.c:EXPORT_SYMBOL_GPL(nr_swap_pages);
...
# diff /home/makerpm/drm-intel/mm/swapfile.c /home/???/linux-4.5-rc2/mm/swapfile.c
51,55d50
< /*
< * Some modules use swappable objects and may try to swap them out under
< * memory pressure (via the shrinker). Before doing so, they may wish to
< * check to see if any swap space is available.
< */
/usr/libexec/gdm-x-session[12729]: (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160124
Un problème insolvable, un gros bug ?
C'est cool, Linux. Surtout quand ça ne fonctionne pas du tout ou que très mal, vraiment très mal. En cas de crashs à répétition, il n'y a pas 36 solutions : on peut abandonner, ou tester d'autres distributions, différentes choses, sinon recommencer tout le temps, ou encore choisir et s'y coller, au chausse-pied, pour adapter une distribution intéressante.
Ben oui, je hacke encore, mais ailleurs, autrement. Et il y a effectivement tellement mieux à faire que d'échanger inutilement ou stupidement avec toutes ces faunes, dont les gens dits de robe, leurs entourages et leurs groupies.
Comment faire pour stabiliser ce modèle de Shuttle avec une Fedora 23 Workstation d'aujourd'hui ? Récupérer les rpm du kernel sur la repo vanilla mainline puis exécuter les quelques commandes, plus bas, et rebooter. Attention, le Shuttle démarrera ensuite avec une version de 4.5.0-0.rc2, une release candidate, susceptible d'être elle-même instable...
Edit : Mon propre Shuttle a d'ailleurs fini par recrasher au bout de 4 à 5 heures de lectures de vidéos (plutôt qu'au bout de 30 à 40 minutes). Je vais voir maintenant ce qui a pu changer du coté de la Fedora, s'il y a eu changement au cours de ces 24 à 48 heures passées. Il y a 48h, j'atteignais un uptime de près de 20 heures, tout allait bien.
Objet | Intel drm random freezes with Z36xxx/Z37xxx and several current 4.x kernels? |
De | Bruno Kant |
À | dri-devel@lists.freedesktop.org |
Répondre à | bkant@cloppy.net |
Date | Aujourd'hui 22:24 |
Hello, According to what I read, video related bug reports could be feed to xorg developpers, they would care about the kernel driver also. Is this an adequate list for such reports? Would you have an easy way to get a diff for Intel Z36xxx/Z37xxx driver, between those two Fedora kernel builds? - 4.5.0-0.rc2.git0.1.vanilla.knurd.1.fc23 As further described below, git0.1 is stable with my XS35V4 Shuttle. But git1.1 often freezes, like some other current kernels dnf installed by fc23. This Shuttle XS35V4 is new, came with the latest XS35V400.400 BIOS installed. I now have a Win10/Fedora 23 dual boot installed on it. Win 10 is stable, I could watch videos with Win 10 during hours. Running Linux is a different story. From the standard Shuttle XS35V4 hardware, a barbone: # lspci -nnk | egrep -iA3 "VGA" With current Fedora 23 kernels, my XS35V4 freezes randomly as soon I'm using X. It frozed also several times during Fedora Workstation installation (a GUI). I had to reboot/restart the install to get Fedora 23 on it. Then I noticed fc23 Xorg freezes after 30 to 40 minutes uptime with load. fc23 Xorg freezed also with no load, takes some more time. fc23 ran stable with gdm/Xorg disabled. Googling around, I found a way to disable Intel DRI/accelleration. My X environnement was stable for hours with heavy load and those next lines added to the box and current 4.3.3 or 4.3.4 fc23 kernels: # cat /etc/X11/xorg.conf.d/20-intel.conf I found also that the Intel driver itself was improved over months. Current Fedora 23 4.3 kernels seem to be build around xorg-x11-drv-intel/2.99.917/16.20150729.fc23, which is of last jully. Digging more in sources, I read: Top of Fedora 23, I installed x86_64 4.5.0-0.rc2.git0.1.vanilla.knurd.1.fc23 from their vanilla-mainline repo. This was stable for hours, with accel and DRI active and with a heavy load for this Celeron (3 video streams plus one VM running in QEMU/KVM). Then I choosed to reinstall fc23 from scratch. And vanilla-mainline repo added kernel version git1.1 (the update) during my latest reinstall. Then my Shuttle started to quickly freeze again. I now forced 4.5.0-0.rc2.git0.1.vanilla.knurd.1.fc23 kernel reinstall on my fc23/XS35V4 box and it seems much stable again, which is why I suggest you to catch this Fedora 23 git0.1/git1.1 Intel driver diff. Best regards |
