Reprise du message précédent :
mes fichiers log de systemd font 6 mo ( system-journal et user-1000.journal ), j'ai fixé la limite à 50 mo dans journal.conf

 
Pour les kernels custom : je package moi même, j'utilise ma propre toolchain si tu préfère, je sais pas comment mieux l'expliquer, c'est de l'administration de base quoi
Mais sinon, pour faire "simple" systemd est PID1 si, PID1 n'arrive pas a gérer le log et fait un overflow, normal que t'ai des kernel panic et des freeze, c't'un peu la base quoi.
Donc vérifiez la vitesse de remplissage de vos logs, si c'est "random" c'est suivant la vitesse a laquelle un buffer ou un log se rempli, donc vérifiez vos foutu log ...  
Pour debugger faut un dmesg pendant un accès FUSE, voir se que vous donne /var/log/kernel.log.0 et vos outils de loggin sur vos distro, si vous arrivez pas a sortir ça, vous pourrez faire les rapports que vous voulez hein

 
c'est déjà fait par exemple :
 
- j'ouvre un fichier mp3 sur une partition ntfs
- je consulte le fichier log de systemd ( journalctl ou dmesg ) : rien d'anormal, aucune nouvelle ligne
 
le bug n’apparaît que dans un cas très particulier ( utilisation d'un logiciel de virtualisation qui fait des lourdes opérations de lecture/écriture sur une partition ntfs ), et encore c'est pas systématique ( le coté aléatoire ),
 
quand le bug apparaît il n'y a rien de suspect dans le fichier log de systemd, à part le kernel trace que j'ai posté dans le rapport de bug, et bien sûr on a un freeze de l'application et le processus "mount.ntfs-3g" qui devient fou ( usage CPU 100% ), et si on a pas de chance on se prend un kernel panic juste après le freeze ( la double peine ),
 
j'ai lancé memtest pour vérifier les barettes mémoire, et un utilitaire de diagnostic pour vérifier l'état de santé du disque dur abritant la partition ntfs : aucun problème détecté, je peux donc exclure une défaillance matérielle, sachant en plus que tout fonctionnait bien avec le kernel 3.15.8

 
C'est pas un problème kernel c'est un problème userspace, donc PID1 pour archlinux. Depuis que tout est géré par systemd sous arch, bonne chance pour trouver la ligne coupable et vue qu'il n'y a que arch qui est impacté, ça viens pas  de la toolchain (ou alors d'autres distos seraient impactées), soit vous avez des units foireuses (fort probable), soit une implémentation de systemd foireuse (fort probable aussi) et le bug se serait mis a apparaître depuis le kernel 3.16 (et il y était déjà avant).
Le seul bug éventuel serait un bug de répartition de charge mais il n’apparaît que si et seulement si votre packager utilise GCC 4.9.x et il serait vraiment très con sachant que c'est Linus himself qui a prévenu : http://www.developpez.com/actu/737 [...] -de-l-ACM/

pour trouver la ligne coupable dans le code source du kernel en général on utilise une fonctionnalité de git : bisect, ça permet de trouver le commit responsable du bug :
 
http://geenux.wordpress.com/2009/1 [...] gressions/
 
c'est de loin la meilleure méthode ( c'est comme ça que je procède par exemple pour traquer les bugs dans le paquet mesa, un autre paquet habitué des bugs ), le seul souci c'est que le kernel prend un temps fou à compiler quand on a pas une machine puissante,
 
du coté des développeurs ils peuvent traquer le bug à l'aide d'un débogueur à condition qu'ils arrivent à reproduire le bug, comme il est aléatoire il faut être patient pour le mettre en évidence

un utilisateur d'ubuntu a aussi le bug "fuse ntfs" :

https://bugzilla.kernel.org/show_bug.cgi?id=82951#c5

j'ai déduit qu'il utilisait ubuntu grâce à la mention "3.16.1-031601-generic" qui est le nom utilisé dans ubuntu pour le noyau 3.16.1

le bug concerne donc potentiellement toutes les distributions linux qui utilisent le noyau 3.16,

une prudence s'impose si vous utilisez des partitions NTFS ( notamment pour sauvegarder des données sur un disque dur externe USB ), il y a peut-être un risque de perte de données, voire de corruption silencieuse du système de fichiers,

c'est toujours délicat ce genre de bug chelou qui touche au système de fichiers, on ne sait pas jusqu'à quel point ça peut déconner, le principe de précaution voudrait qu'on évite d'écrire sur les partitions NTFS tant que les développeurs n'ont pas trouvé le commit responsable de tout ça

 
Retour sur cette histoire de déconnexion d'affichage.  
J'ai pousser les tests un peu plus loin.  
 
J'arrive à reproduire sur arch le fonctionnement que je voulais mais avec ... xen. Donc c'est bien le module xen-pciback qui fait un boulot pour couper tout ca. Le couple pci-stub/vfio n'est pas aussi puissant.  
 
Je peux dire donc que c'est pas spécifique à arch/systemd. Et je peux pas avoir du xen et qemu/kvm sur la même machine. Ca m'arrange pas tout ca

il y a pas moyen de te créer un paquet "xen-pciback" pour que le module puisse être chargé par le noyau ?
 
regarde du coté du dépôt AUR, un tel paquet existe peut-être déjà
 

C'est pas bête ce que tu dis mais j'ai déjà essayé de chargé le module xen-pciback en bootant avec un noyau standard et pas un noyau xen. Et ca marche pas. Je vais quand même jeter un coup d'oeil a ce que tu me dit, on sait jamais.

 
Ton anti systemd est un peu limite la... J'espère bien que tu parles de gcc pour cette histoire de toolchain parce que j'ai pas franchement l'impression que justement on tous la même version utilisé pour compilé les packages binaires entre Arch et les autres distro non-rolling release, et c'est pas comme gcc n'était un peu foireux avec la 4.9 dernièrement (enfin des bugs en 2.95, j'en ai eu aussi et des vraiment dégueulasses) comme tu l'as dit. En plus ton "analyse" est légèrement foireuse car si on repasse avec la même version de systemd mais un kernel précédent, ça ne foire pas, mais si tu mets l'ancien systemd avec le 3.16, bah à plus sous le bus(-error)... Et cette histoire de PID1-ki-kache-tout c'est une blague que tu peux faire à ceux qui pipent rien, mais la, c'est limite du niveau à troll du vendredi.
 
Bref ;/

 
Bah ça cache effectivement tout, parce que si au moins t'avait une verbosité suffisante sur tes logs tu verrais d'où ça viens, là c'est mystique. Et j'espère pour toi que ça viens effectivement pas de systemd, mais accuser l'upstream alors que justement des tests de régressions sont fait pour éviter ce genre de soucis. Quant à la toolchain, ça veux bien dire se que ça veux dire : http://fr.wikipedia.org/wiki/GNU_toolchain
 
Donc a partir de là, soit ça viens de votre userspace sous arch qui est foiré
Soit votre packager de kernel respecte pas l'upstream
Et entre nous, je préférait grandement (pour vous) que ça soit votre userspace, et pour debugger tu commence déjà par voir si la glue est OK donc PID1 avant de descendre et de debugger le reste.

Des tests de non-regression ? Depuis quand y en a sur le noyau ? Ou bien j'ai mal compris.
 
J'ai pas non plus compris comment c'est passé de linux/fuse/ntfs-3g à systemd

 
Le terme Toolchain n'existe pas que pour gcc, mais c'est pas grave.
 
Ne pas respecter l'upstream ? C'quoi l'upstream dans ce cas la ? 100% source kernel unpatched ? 100% defaut kconfig ? quelle version de gcc ? quel flags du compilation ? Cross compilation (pas?) autorisée ? So ? Bah si tu veux plus d'informations c'est la que ça se passe : https://projects.archlinux.org/svnt [...] ages/linux
 
Non, mais des bugs dans le kernel, c'pas comme si y'en avais des dizaines de corrigés par semaine avec les releases hebdomadaires. Et franchement systemd change rien dans la façon de faire, c'est parfois aberrant les complaintes de ceux qui s'en servent même pas.

Ce qui est aberrant c'est de voir comment t'es agressif dès qu'on critique un projet qui est critiquable sur énormément de points et de pas reconnaître les faiblesses du dit système.
 

 
Très simple : Elbarto parle d'un bug et accuse directement le kernel de pas supporté, je dit que ça peu venir d'autre chose, comme la gestion de l'userspace (fuse est un kernel linker > userspace), je dit que le problème peut venir d'une autre brique :
-toolchain
-module fuse
-ntfs-3g
-systemd (depuis que, je le rappel, c'est lui qui gère votre userspace)
 
On sait que la toolchain est foirée, on sait qu'il y a des bugs dans la journalisation de systemd, ça nécessite investigation sans forcément directement remonter a l'upstream, mais dès que tu parle d'une chose qui approche systemd Ralph- se fait une joie de protéger le bouzin. Je continue d'expliquer mon raisonnement, mais que veux-tu, quoi qu'il arrive, il remet tout sur la personne et se qu'elle pense du système sans analyser réellement se qu'elle dit (en l'occurence, moi) > attaques ad hominem > pour moi c'est un troll velu. Qui non seulement parle de FUD et d'argument d'autorité (a peine voilé) mais se prive pas d'en faire.

 
De un tu ne l'utilises pas, autant dire que les critiques de ce genre sont à peine reloud.
 

 
 
Maintenant, j’apprécie te lire sur certains topics où l'on voit que c'est ton taf et que tu touches vraiment, et crois moi que la, je n'irai pas te contredire ou te reprendre car je n'ai pas 20% de tes connaissances dans ces domaines bien spécifiques. Cependant, ton trolling quasi-permanent de systemd (sans l'utiliser tant qu'à faire) me gonfle, on croirait lire des personnes qui crachent sur le dernier OS de Redmond sans bien sur l'avoir essayer, c'est tout aussi pathétique. Et je trouve ça dommage car du coup, ça pousse à être plus septique sur les sujets pré-cités (et je trouve vraiment ça dommage, sincèrement).
 
Je ne protège rien, je ne suis pas un fanboy et je n'ai pas d'action chez RedHat, j'apprécie systemd car je l'utilise tous les jours (et toi jamais) et pour diverses choses (genre de l'embarqué, etc etc), et j'utilise d'autres distros et même des BSD (et pas depuis 2 ans, mais... 17 la). Elbarto n'est pas non plus tombé de la dernière pluie, il teste vraiment beaucoup et j'ai plutôt confiance en lui qui utilise Arch (et donc systemd) que quelqu'un qui tente de casser du sucre sur RH et LP, et comme pour lui ça penche plutôt coté kernel (et vu l'enchainement de tests qu'il a fait, je suis du même avis aussi, c'pas comme si on s'en mangeait pas des régressions avec la sortie d'un noyau 3.x.0 et 3.x.1, mais c'est le lot des Rolling release, si ça fait chier, il faut passer à autre chose.

 
dans la mesure où un downgrade ( installation d'un noyau de version inférieure ) vers le noyau 3.15.8 résout le problème alors il y a de bonnes chances que le problème soit dans le noyau 3.16.x,
 
il peut y avoir d'autres hypothèses mais pour l'instant on se concentre sur la plus probable, un développeur du noyau qui a voulu introduire une nouvelle feature, une optimisation, un nettoyage de code mais patatras il a aussi introduit un bug, une régression, c'est très classique comme pépin dans le monde du développement logiciel
 
on devrait connaître bientôt le fin mot de l'histoire car dans le forum français d'archlinux quelqu'un s'est dévoué pour faire un git-bisect afin d'identifier le commit qui a introduit le bug

J'ai un vieux bug intermittent avec mon pointeur de souris, je ne sais pas d'où ça vient.
 
Le pointeur se retrouve doublé et tordu, avec un bout de dossier en dessous.
 

 
Pourquoi cette photo pourrie ? Parce que le pointeur apparaît correctement sur une capture d'écran.  
 
Puis le bug s'en va comme il est venu.

Meme soucis avec un autre gestionnnaire de fenetres?

Ca sent un bug dans le driver X / CRTC.  
Quelle driver d'ailleurs ?

xf86-video-intel (i915)
 

Pas encore essayé !

AMHA ca vient de cela soit de X.
Si le probleme est recent, regarde quand ces paquets ont change.
Si le probleme est frequent, tente de revenir a une version anterieure de ces paquets et voir comment ca se passe.
 
Sinon question pour ceux qui utilisent ZSH, comment changer l'auto-complete de mplayer/mpv ? J'aimerais enlever tous les protocoles et garder uniquement les fichiers locaux dans le complete mais je ne sais pas comment faire cela proprement.

quelqu'un ici a l'habitude d'utiliser qemu ( ou kvm ) pour les machines virtuelles ?
 
j'utilise une des fonctionnalités de "spice" pour avoir le copier-coller entre l'OS host et l'OS guest :
 
https://wiki.archlinux.org/index.ph [...] _and_paste
 
ça fonctionne, mais si je redémarre la machine virtuelle ( menu "reboot" dans l'OS guest ) alors qemu fait systématiquement un segfault, et cela uniquement si je fais un reboot de l'OS guest ( une extinction de l'OS guest n’entraîne pas de segfault ) :
 

 
si je n'utilise pas la fonctionnalité de copier-coller de spice ( qui consiste à créer un virtserialport ) alors je n'ai pas de plantage au reboot, on dirait un bug ( ou une feature comme dirait l'autre ),
 
ça le fait quelque soit l'OS guest ( windows ou linux )

 
essaye le noyau lts

ou le 3.15.8, c'est peut-être la branche 3.16.x qui pose problème,

en plus on est qu'à la version "1" du noyau 3.16, il me semble qu'en général c'est pas toujours stable et qu'il faut attendre les versions 4 ou 5  pour être sûr que les régressions et les bugs ont été corrigés

Y a de grandes chances que ce soit le dernier X avec glamor.
Je dis de tester un autre noyau pour isoler

Ou sinon dowgrader X, mais c'est plus chiant

Le pire c'est que ça bug un peu quand ça veut, c'est pas ultra fréquent non plus.

J'ai une question "casse système" sur une arch64.
 
J'ai vu que The witcher 2 était sorti en version GOG/Linux et, comme cela a attisé ma curiosité, j'ai voulu tester. Bon, comme prévu, c'est un jeu 32 bits donc il a tout de suite chialé pour avoir des lib32 (SDL), chose que j'ai fait de suite sauf qu'en fait, la version Sdl2_image n'existe pas en multilib et là je sèche un peu.
J'ai voulu installer la version i686 mais cela ne marche pas (pas de surprise mais bon j'ai testé) puis j'ai voulu compiler les sources en me basant sur:
https://wiki.archlinux.org/index.ph [...] ib_Project
Et, au final, bah euh rien. Cela m'indique toujours que l'architecture est incompatible.
 
Bref, ou comment un paquet de 39Ko peut bloquer un autre de 20 Go.

ton histoire de GOG ça fait référence à ça ? ( je suis pas du tout gamer )  
 
http://fr.wikipedia.org/wiki/GOG.com
 
c'est un jeu à la base pour linux 32 bits ?
 
si oui alors ça devrait tourner sur du linux 64 bits en utilisant la version 32 bits de mesa dans le dépôt multilib ( lib32-mesa ), ça devrait installer ensuite d'autres paquets commençant par "lib32" au niveau des dépendances ( systemd, pour le son etc... ),
 
c'est comme avec un windows 64 bits --> tu peux toujours faire tourner des programmes 32 bits grâce à l'installation de librairies 32 bits en plus de la version 64 bits, la logique reste la même avec un linux 64 bits, faut que tu installes la version lib32 des paquets en question,
 
sinon un peu de lecture :
 
https://bbs.archlinux.org/viewtopic.php?id=184704

Tu décris parfaitement ce qu'il faut faire... ...tu as juste zappé le fait que c'est ce que j'ai fait sauf qu'il me manque la lib32sdl2_image.
https://www.archlinux.org/packages/ [...] =&flagged=
Là, tu as la version 32 bits sdl en multilib.
https://www.archlinux.org/packages/ [...] =&flagged=
Là, pas de multilib.
Manque de chance, le jeu demande la lib32sdl2_image.
 
Ce que je ne comprend pas trop, c'est pourquoi un paquet i686 (32bits)même compilé par moi-même ne peut pas s'installer sur du x64 alors qu'un paquet i686 de la multilib va lui bien s'installer??
J'ai peut-être merdé dans la compilation. Pourtant j'ai bien utiliser Gcc-multilib et modifier le makepkg.conf.

je pense que dans le fichier PKGBUILD du paquet il faut qu'il y ait une précision pour indiquer que le paquet est destiné à une architecture 64 bits, c'est le cas pour les paquets "lib32-machinchose",
 

 
ce paquet est disponible sur AUR :
 
https://aur.archlinux.org/packages/lib32-sdl2_image/

   
Euh, je dois être ultra bourré (disons que je nie pas le fait d'être dans un état similaire sans produits à la con=>fatigue. ) mais je ne vois pas ou tu le trouves.

Pinaize!    
 
J'y ai pensé, c'est ça le pire.    
 
 
Merci quand même, il ne reste plus qu'à me cacher.  

j'ai supprimé une partie de mon message car je viens comprendre ton problème, tu as été trop rapide

sinon ton paquet est disponible sur AUR, ça devrait résoudre ton problème

en mettant aujourd'hui à jour mon système j'ai cet avertissement de pacman :
 

 
pourtant je n'utilise pas le dépôt testing, donc pourquoi est-ce que soudainement la version du paquet kdeedu-kig a été rétrogradée à la version inférieure dans le dépôt extra ?
 
la version 4.14.0-1 date du 16 août dernier, et la version 4.13.3-2 du 7 septembre,
 
dans le doute j'ai crée un rapport de bug, il est possible que le mainteneur de ce paquet ait merdé dans la version de son fichier PKGBUILD en créant le paquet

Il y a de grandes chances qu'ils aient juste fait de la merde en voulant rétrograder sans utiliser l'epoch.

attention si vous utilisez kde et le paquet phonon-qt4-gstreamer pour la gestion du son,
 
le paquet phonon-qt4-gstreamer est passée en version 4.8.0-1 aujourd'hui, et de manière surprenante le mainteneur de ce paquet a décidé que pulseaudio était maintenant une dépendance obligatoire    :
 
https://www.archlinux.org/packages/ [...] gstreamer/
 
conséquence : si vous aviez l'habitude d'utiliser phonon-qt4-gstreamer sans cette usine à gaz de pulseaudio ( en gros vous utilisez uniquement alsa ) alors ça va foutre le bordel dans votre configuration du son, car dorénavant pulseaudio va se lancer automatiquement à chaque boot et imposer son serveur de son parfois source de problèmes et de bugs    ,
 
ainsi sur mon portable de 2003 équipé d'un banal AC97 comme carte son interne pulseaudio déconne à fond, le son est systématiquement à 100% dans le mixer,
 
du coup j'ai viré phonon-qt4-gstreamer et pulseaudio pour utiliser à la place phonon-qt4-vlc qui n'a pas besoin de pulseaudio,
 
je pense que je vais créer un rapport de bug pour demander au mainteneur s'il est vraiment necessaire d'avoir pulseaudio comme dépendance, car la précédente version de phonon-qt4-gstreamer n'avait pas besoin de pulseaudio
 
edit: je viens de reconstruire le paquet phonon-qt4-gstreamer en modifiant le PKGBUILD ( j'ai retiré pulseaudio de la liste des dépendances obligatoires ), et ça se compile sans problème, ça semble indiquer donc que pulseaudio n'était pas obligatoire, j'ai donc crée un rapport de bug
 
edit 2 : problème corrigé avec une nouvelle version du paquet suite à mon rapport de bug  
 
en fait ils ont été induits en erreur par un forumeur qui a fait un diagnostic erroné et qui a demandé l'intégration de force de pulseaudio dans phonon-qt4-gstreamer, alors que cela n'avait aucun sens de faire ça  :
 
https://bugs.archlinux.org/task/366 [...] &sort=desc

Ce post qui se suffit à lui même
 
XaT

Merci Elbarto, ca me renforce dans mon idée de switcher sur OpenBSD à plein temps

Allez me trouver un autoradio en ogg