Reprise du message précédent :
j'ai pu isoler le paquet qui crée le problème ( kernel panic dans l'host ) : il s'agit du noyau linux 3.16.x,

car quand je downgrade vers le noyau 3.15.8-1 je n'ai plus le bug !

j'ai pu remettre sur pied ma machine virtuelle archlinux avec un chroot pour faire un fsck de la partition virtuelle et réinstaller certains paquets ( le kernel panic s'était produit en plein pacman -Syu de ma machine virtuelle, j'ai eu du coup un db lock de pacman, par précaution j'ai réinstallé les paquets du dimanche en consultant le fichier pacman.log ),

bref prudence avec le kernel 3.16.x si vous utilisez virtualbox, il y a quelque chose de pas net entre les modules virtualbox  ( ou virtualbox lui même ) avec le noyau 3.16.x, une mauvaise interaction,

le fait d'utiliser le pilote libre radeon et/ou un CPU intel de type pentium dual core E6800 peut faciliter le bug si ça concerne un problème avec Vt-x

@Elbarto, pour la petite histoire, je sais pas si ça s'est arrangé depuis:
https://lkml.org/lkml/2011/10/6/317

Tu as quelle version de VB ? Parce que la 4.3.14 sous Windows en Host est vraiment pas stable, ils ont du sortir une 4.3.15 en beta le temps que ça marche mieux, vivement la 4.3.16.

j'utilise le paquet officiel d'archlinux pour virtualbox, la version utilisée est la 4.3.14-3,
 
j'ai refait un nouveau test avec le kernel 3.16.1-1, ça semble assez aléatoire car parfois j'ai pas le bug, et parfois je l'ai, toujours après un temps aléatoire ( 5 à 15 minutes ),  
 
le symptome c'est soit un kernel panic ( dans l'host, c'est à dire qu'on perd tout, obligé de faire un reset du PC ), soit un gel de virtualbox et là c'est moins grave car on peut redémarrer, même si c'est difficile car systemd n'arrive pas à arrêter virtualbox ( processus zombie ) , ça donne une extinction bizarre avec l'écran qui s'éteint brutalement, je suis alors obligé de faire encore un reset,
 
j'ai fait un rapide memtest au cas où ça viendrait de mes barettes, tout est ok mais je vais refaire un memtest beaucoup plus long
 
 
 
 
c'est intéressant, ils auraient donc ajouté un tag pour indiquer que le driver vboxdrv est "sale" ?
 
mais je ne sais pas ce que fait exactement la fonction add_taint()
 

 
la photo de mon kernel panic, les dernières lignes :
 

un utilisateur de virtualbox sous archlinux semble avoir un problème similaire :
 
https://bugs.archlinux.org/task/41556?project=0
 
c'est tout en bas dans les commentaires ( l'utilisateur Alim Gokkaya )
 
j'ai quasiment les mêmes messages d'erreurs dans journalctl que lui :
 

 
https://bugs.archlinux.org/task/41597?getfile=12116

La nouvelle facon de gerer java pose probleme avec netbeans: https://bugs.archlinux.org/task/41603

Workaround facile cela dit.

pas de soucis avec eclipse par contre

 
Ca "teinte" le kernel, si tu rapportes un bug à des dev kernel, et que ton kernel est "teinté", ça va directement apparaitre dans tes logs et il ne fera pas confiance ou ignorera ton bug report.

Souiller (taint) d'ou le rejet immédiat des dèvs.

les développeurs du noyau ont une si mauvaise opinion que ça de virtualbox ?  
 
du coup quel est l'outil de virtualisation fiable préconisé par les développeurs du noyau ?
 
j'ai choisi virtualbox parce que ça me semblait sympa à utiliser, user-friendly, pas mal de fonctionnalités, mais s'il y a mieux et fiable je suis preneur

Ils ont une mauvaise opinion de tout ce qui est en dehors de linux en fait
Alors que du KVM/Qemu c'est dans l'arbre et ça cassera moins souvent.

Qemu avec support KVM

qemu/kvm et virtualbox n'ont vraiment pas la même cible, et oui le second est très user frendly et permet des trucs assez puissant (je ne me lasse pas du seamless mode)

sinon pour mon souci avec virtualbox ( freeze et parfois kernel panic ) ça pourrait venir du mode "fuse" de montage des disques,
 
car ma machine virtuelle se situe sur une partition ntfs montée de cette manière :
 

 
l'hypothèse serait que virtualbox envoie une requête d'accès à cette partition et qu'en retour le kernel 3.16.x patauge dans la semoule ( un bug quelque part dans la gestion "fuse" ), virtualbox n'a pas sa réponse et du coup il ne peut plus écrire sur la partition --> freeze de l'application et parfois kernel panic de l'host
 
sur le forum archlinux un utilisateur a constaté qu'en déplaçant sa machine virtuelle d'une partition NTFS ( disque dur USB ) vers son /home le bug disparait
 
pour rappel le trace aboutissant au kernel panic contenait ces lignes :
 

 
des mentions "fuse_copy" et un "device_not_available" qui m'interpelle  
 
est-ce que dans le bugzilla du kernel il y a un bug ouvert concernant le montage fuse ?

gros plaisir hier de revenir sur une vieille conf sous arch + dwm et de lancer un vaste pacman -Syu sans rien casser en 30 secondes

n'oublie pas les éventuels fichiers "pacnew" qu'il ne faut pas négliger, sous peine d'avoir un fonctionnement possiblement chaotique des applications

La blague, kde 4.14 a été poussé en stable, mais akonadi est resté en testing.
Si on upgrade, on casse kde-pim, il faut aller chercher la maj d'akonadi en testing soi même...

merci de l'info, j'ai pas encore fait la mise à jour,
 
peut-être la conséquence du mois d'août, le mainteneur d'akonadi en vacances
 
c'est comme pour vlc qui normalement aurait dû être recompilé pour prendre en compte la dernière version de ffmpeg ( car la version actuelle plante sur certains codecs, en recompilant il n'y a plus de problème ), mais le mainteneur du paquet est aux abonnés absents

Merci de l'info pour kde. Je ferai l'update en rentrant de vacances

Petite info pour les utilisateurs de vim : https://www.archlinux.org/news/reor [...] m-packages

Ouais j'ai du switché sur le vim-minimal sur 2 machines la  

Au passage pour kde 4.14 et akonadi, on perd les ressources google calendar et contacts...

c'est quoi ce bin's concernant le renommage des paquets libreoffice ?
 
en voulant faire un pacman -Syu je tombe sur ces questions :
 

 
j'ai répondu oui mais j'ai pas encore validé, un changement cosmétique de nom pour ces paquets ?

Pas vu de différence dans l’interface de « Writer ».

bon apparemment ils ont fait le même truc que pour vim, une réorganisation avec la possibilité d'installer soit la version béta, soit la version de maintenance de libreoffice :.
 

 
https://wiki.archlinux.org/index.php/Libreoffice
 
ils auraient pu faire une news en page d'accueil, libreoffice c'est aussi pas mal utilisé, sans doute plus que vim

Il semble qu'il y a bien un changement de nom pour les paquets libreoffice quand je regarde sur le site d'Archlinux

Pour LO c'est complètement stupide d'avoir renommé les packages...
C'est juste que LO a plus ou moins 2 versions en parallèle, mais les versions étaient suffisantes pour savoir de quoi on parlait...

finalement la news sur LO on ne la retrouve qu'après avoir fait le pacman -Syu et validé les réponses aux questions, dans la sortie de la console et dans le fichier pacman.log :

en gros on est averti qu'après avoir validé le changement de nom, c'est un peu dommage, il aurait été plus logique d'afficher cette news lorsque la question a été posée pour le changement de nom, afin que l'utilisateur puisse mieux comprendre les enjeux de la question

en fait le renommage ce n'est que pour faciliter le switch d'une branche à l'autre

Hola !

Je fais du arch en ce moment pour le kvm et passthrough. Avant je tournais sur du slackware et xen.
Sur la slackware (et le noyau xen ?)je pouvais "déconnecter" la carte graphique intégré intel de facon a ce que je n'ai plus d'écran sur la machine hôte. J'arrive pas à reproduire le même fonctionnement sur arch.

Quelqu'un aurait une idée du pourquoi du comment ?

edit: j'avais un doute avant mais la je confirme que c'est le module pciback de xen qui faisait ca sur la slackware.

ça a l'air pointu comme question, sur le wiki il y a un bon article sur qemu et kvm qui donne les bases pour installer tout ça sous archlinux :
 
https://wiki.archlinux.org/index.php/QEMU
 
https://wiki.archlinux.org/index.php/Kvm
 
https://wiki.archlinux.org/index.php/Xen

Oui j'imagine que c'est un peu pointu mais je me suis dis que des fois que j'aurais zappé quelquechose de simple ...  
 
Merci pour les liens mais effectivement ca parle juste de l'installation
 
Je reste à l'affut des fois que quelqu'un ai une idée à soumettre

C'est certes pointu mais pour moi ça n'a pas grand chose à voir avec slack/arch c'est purement linux là.
Peut-être pas la même version de noyau, peut-être pas les mêmes patchs, peut-être pas la même configuration, etc... faut investiguer.
Tu ne décris pas ton problème d'ailleurs.

Il veux déconnecter son affichage et qu'il ne soit pas initialisé par la distro, surement pour l'assigner a une VM. Pas possible sous arch a moins d'avoir une carte capable de faire du GPU sharing/PT a cause de systemd : systemd ne sais pas unload un module hardware a chaud s'il est toujours présent électriquement dans la machine et actif, il voudra conserver la main dessus et lui assigner des ressources pour le dom0.

 
Je suis d'accord que c'est pas spécifique à une distribution mais plus à linux. Mais comme je fais ca sous arch, je me suis dis que je vais poser la question ici aussi des fois que il y ait une information qui sorte. Je continue de chercher de mon coté de façon générique  
 
D'ailleurs c'est pas tant un problème. C'est juste une réflexion que je me fait sur le fait de savoir si le fonctionnement que j'ai est normal ou pas.  
 

 
Oui c'est bien de ca que je parle.  
Quand je fesait mes tests sous slack/xen, à un certain stade du démarrage de la machine, l'écran s'éteignait et le restait jusqu'a ce que je démarre une vm avec la cg assignée dedans en passthru. Pour rentrer un peu plus dans le détail, quand la machine hôte démarrait avec le noyau xen, le module xen-pciback prenait la main sur la carte graphique en lieu et place du pilote de cette dernière. Du coup pas d'affichage.  
 
Avec kvm et vfio/pci-stub, je n'arrive pas à reproduire ce fonctionnement du coup je me dit que si je passe la carte graphique en passthru à une vm, vu que la carte graphique à été initialisée et l'est jusqu'au démarrage de la vm, il peut y avoir des problèmes.  
Mais comme le dit MysterieuseX, c'est peut être du à arch. Il faudra que je fasse des tests pour voir si j'arrive dans un premier à faire marcher cette configuration sur une autre distribution et si le fonctionnement est identique.  
 
D'ailleurs MysterieuseX, tu dis que c'est pas possible de le faire à moins d'avoir une carte capable de faire du gpu sharing et/ou PT. Qu'est ce qui caractérise une telle carte et comment savoir si celle ci peut le faire ou pas ? Sous xen j'ai réussi à faire pt avec le controleur graphique intégré igd 4600. Elle rentre donc dans cette catégorie ?
 
Edit: Je viens de tester le cas où je passe le igd 4600 à une vm en passthru et l'écran ne s'allume pas. Pourtant la vm derrière marche bien parce que j'ai le son et que je peux interagir avec la vm. Ca m'arrange pas
Avec une carte gtx 780ti pas de soucis par contre.

les témoignages semblent se multiplier chez les utilisateurs d'archlinux pour confirmer un problème dans le kernel 3.16 concernant la gestion des partitions montées avec "FUSE" ( cas des partitions ntfs quand on utilise ntfs-3g ),

c'est un bug difficile à reproduire mais qui a de fortes chances de se produire si vous utilisez un logiciel de virtualisation dont le fichier de machine virtuelle se trouve sur une partition ntfs, plus le fichier est gros ( genre 25 Go ) plus il y a un risque que le bug se produise ( entraînant un freeze de l'application, et parfois un kernel panic ),

ça se produit particulièrement quand il y a beaucoup de lectures/écritures sur le fichier situé sur la partition ntfs,

j'ai eu le bug en utilisant virtualbox, mais aussi avec qemu/kvm, un bug aléatoire,

un rapport de bug a été crée :

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

pour l'instant je n'ai recensé que des utilisateurs d'archlinux déclarant avoir ce problème ( via les forums français et anglais d'archlinux ), les utilisateurs de gentoo semblent mystérieusement épargnés

il se peut que ça soit en fait un problème de packaging du kernel chez archlinux, ou un bug de la version de GCC utilisée, voir glibc ?

le lien vers le forum français d'archlinux sur ce problème :

https://forums.archlinux.fr/topic15778.html

 
Vérifie l'écriture de ton log, ressemble vaguement a une saturation des logs provenant de l'userspace et pas un bug kernel. Si tel est le cas, je te dirai d'où viens le problème.

j'ai rien compris à ton message    
 
c'est quoi une saturation des logs ?
 
en tout cas en downgradant le kernel à la version 3.15.8 il n'y a plus de problèmes,
 
vu que tu utilises archlinux essaie de reproduire le problème avec le cas d'utilisation que j'ai donné ( virtualbox + grosse machine virtuelle en terme de giga-octets sur une partition ntfs + grosse procédure I/O, un pacman -Syu par exemple dans la machine virtuelle, au bout d'un temps aléatoire qui peut se compter en heures le bug va fatalement se produire ),
 
l'idéal ce serait de faire un git-bisect pour identifier le commit responsable de ce problème, mais c'est long et fastidieux ( le bug étant aléatoire et j'ai pas une machine puissante pour compiler rapidement )

 
J'utilise sur toutes les distros que j'ai des kernels custom, donc sans bugs, mais il y a des problèmes de verbosité dans les logs avec systemd et je pressent que de manière similaire au bug "debug" qui floodait le kernel, ils aient collés le même truc sur certaines commandes userspace qui affecteraient FUSE. Une sorte d'overflow si tu préfère, donc soit c'est un problème de logs FUSE, soit un problème de logs systemd soit un problème de logs kernels.

en quoi un problème de verbosité dans un log peut entrainer un freeze, voir un kernel panic ?

ici dans mon cas le freeze/kernel panic est provoqué par une perte d'accès brutale à la partition ntfs ( quand le bug se produit je ne peux plus accéder à la partition NTFS avec Dolphin, et le processus mount.ntfs-3g utilise 100% CPU )

si tu as des pistes, voir une idée du commit qui a provoqué le problème n'hésites pas à en parler sur le rapport de bug, histoire de relancer la chose, car pour l'instant j'ai l'impression que mon rapport de bug n'est pas trop pris au sérieux par les gens du kernel, surtout que ça touche que les utilisateurs d'archlinux, ils doivent peut-être se dire que c'est un problème de packaging lié à archlinux

qu'entends-tu par "kernel custom" ?
si c'est juste une modification du fichier de configuration des options du noyau alors ça changera rien, tu auras le bug quand même je pense

Sachant que la config de taille max des log du journal de systemd est buggée

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