Reprise du message précédent :

Qu’est-ce qui te met sur cette voie ?

donne nous des détails

chez moi c'est aléatoire, le blocage apparait tous les 5 à 10 boots, pour le mettre en évidence il faut rebooter jusqu'à ce que le blocage apparait,

lorsque le blocage apparaît il faut attendre 5 minutes avant que systemd affiche le message : "task systemd-udevd blocked for more than 120 seconds"

si on a utilisé l'option "debug" dans les options de boot de grub ( ou syslinux ) alors on verra aussi un kernel trace

ensuite je suis obligé de faire un RESET car systemd ne s'en sort pas,

je suis en train de compiler le kernel 3.18rc3 pour voir si le bug est présent aussi dans cette branche mainline

je vais tester aussi la version testing de systemd :
 
https://www.archlinux.org/packages/ [...] 4/systemd/

J'ai fait 12 reboot avec un Intel I5 760 + Intel DH55C + syslinux et le firmware CPU chargé + ArchiLinux mise à jour (Kernel 3.17.2), je n'ai pas encore eu de blo
 
Il doit être vicieux à trouver ce bug.

peut-être que c'est un bug lié à gcc lors de la création du paquet systemd, un bug qui se produit qu'avec certains types de CPU ?

ou un bug du kernel 3.17.2 ?

le mainteneur du paquet qui a un système moisi au niveau des dépendances et des versions de librairie ?

j'avais eu ce cas sur un paquet KDE, en reconstruisant le paquet avec le PKGBUILD le bug que j'avais  avait disparu,

là j'ai compilé la version 3.18rc3 mainline et je n'ai pas encore réussi à avoir le bug après 15 reboots

Avec la même config que le kernel Arch ?
 
https://projects.archlinux.org/svnt [...] ages/linux

oui c'est identique, j'ai pris le paquet aur "linux mainline"

mauvaise nouvelle : j'ai encore eu un blocage au boot malgré le noyau 3.18rc3,
 
du coup je me demande si c'est pas plutôt un problème matériel chez moi, un disque dur qui commence à lâcher, une carte mère pas très en forme ( mais ce serait étonnant car j'ai aucun problème une fois que le boot s'est bien passé ),
 
ou bien un bug de systemd ( j'ai essayé la version testing 217-5 au cas où mais ça change rien ),
 
on devrait avoir la réponse lorsque les autres distributions linux commenceront à basculer vers le kernel 3.17 et les versions plus récentes de systemd

je viens d'installer le noyau 3.16.4 et après de nombreux reboots le bug ne s'est jamais produit,
 
donc le fautif est très certainement le noyau 3.17.x, les développeurs ont dû mettre quelque chose qui gène terriblement le boot sur mon PC,
 
ça ressemble à un problème de timing ou de synchronisation entre processus, une "collision", 2 processus qui veulent acceder en même temps à une ressource, comme cela n'est pas possible ça crée alors une situation de blocage qui donne l'impression d'un freeze, c'est mon hypothèse,
 
sur des CPU lents comme le mien ( un pentium dual core E6800 3.33 Ghz ) le bug se produit facilement, et peut-être que sur des CPU récents le bug ne se produit pas car la collision n'a pas le temps de se produire ?
 
bref je suis coincé, il faudrait qu'il y ait d'autres utilisateurs touchés par le bug pour que les développeurs du noyau commencent à s'interesser à ce bug,
 
ou bien que je trouve moi même le commit qui a crée ce bug, pas évident car mon PC n'est pas assez rapide pour faire un bissect avec GIT, ça prendrait beaucoup trop de temps, surtout sur un bug qui est aléatoire ( ça se produit tous les 5 à 10 boots ),
 
il faudrait que j'inspecte le changelog du noyau 3.17.0 afin de cibler les commits suspects
 
ma configuration :
 
archlinux 64 bits
cpu pentium dual core E6800 3.33 Ghz
carte mère gigabyte GA-P31-DSL3 ( chipset intel P31 )
ati radeon HD4650 PCIe ( radeon open source driver )
3 disques SATA branchés sur la carte mère
1 graveur DVD SATA branché sur la carte mère
1 disque IDE branché sur la carte mère
1 disque IDE branché sur une carte PCie contrôleur SATA/IDE JMicron JMB363/368

Avec ccache, et en gardant bien ton repertoire de compilation, ca doit pouvoir se faire en un temps pas trop mauvais.
 
Mais avant de se lancer la dedans, il faudrait etre sur que ca vient bien de Linux 3.17, vu que quand tu as mis 3.18 tu pensais que c'etait bon mais en fait non... peut etre que ca sera pareil avec 3.16.

j'ai fait plein de reboots pendant une demi-heure, toujours pas de souci avec le noyau 3.16.4,

je vais encore rester plusieurs jours avec le noyau 3.16.4 pour être certain mais je suis assez sûr que le problème vient du noyau 3.17,

pour la compilation je crée en fait un paquet archlinux pour le noyau, du coup c'est pas vraiment une compilation à "l'ancienne" de type "/configure, make, make install", car j'utilise makepkg qui fait tout le boulot à partir du fichier PKGBUILD fourni par arch pour le paquet du noyau

Ca ressemble a un soucis dans le mkinitcpio.conf
Essaye de transférer celui du package build du 3.16.4 vers le 3.17.0 et fait juste le build de l'init (en oubliant pas de le mettre au bon endroit etc ...)

je ne suis pas sûr de comprendre ta demande,

car j'utilise le même fichier /etc/mkinitcpio.conf, il n'a pas bougé entre le noyau 3.16.4 et le 3.17.x

j'ai essayé de supprimer "radeon" dans modules mais ça n'a rien changé, toujours le bug avec le noyau 3.17.x et 3.18.x,

la piste que je n'ai pas encore exploré c'est le fichier config.x86_64 qui contient la configuration du noyau avant compilation, des choses ont changé dans ce fichier entre la version 3.16.x et 3.17.x, des nouvelles options sont apparues, signe que des choses nouvelles ont été ajoutées dans le noyau 3.17.x

ainsi il y a une nouvelle ligne qui est apparue par exemple :

vu que le bug n'apparait qu'au boot ( une fois qu'il a passé le stade du boot il n'y a aucun problème ) alors c'est peut-être quelque chose liée à l'initialisation, quand le noyau essaie de détecter le matériel, une histoire de timing, comme les histoires de "FAST TSC calibrated failed", un bout de code moisi qui entraine un boot pas fiable

quand le freeze apparait au boot je peux lire parfois ce message d'erreur qui donne l'impression que les disques sont mal initialisés avec le kernel 3.17 et 3.18 :
 

 
https://bugzilla.kernel.org/attachment.cgi?id=156871

EH les mecs, on a trouvé le dernier utilisateur de la couche ata !
Regarde déjà si les disque bien branchés, le câble la nappe IDE a peut-être bougé ?
 
Pour tes tests aussi, essaie des arrêts/démarrages plutôt que des redémarrages à chaud.

les disques sont bien branchés puisque lorsque je teste avec le noyau 3.16.4 il n'y a pas de problèmes,
 
et attention c'est pas parce qu'il y a marqué "ata" que ça signifie que ce sont des disques IDE, en réalité ce sont des disques SATA,
 
la subtilité c'est que j'ai une vieille carte mère de 2007 ( gigabyte GA-P31-DSL3 ) qui a une couche d'émulation IDE pour les disques SATA ( contrôleur disque intel ICH7 ), mais c'est bien du SATA
 
le bug se produit aussi bien à froid qu'à chaud, ce qui me fait dire que c'est purement logiciel, ou un bug ACPI du noyau 3.17

je ne suis plus tout seul à avoir le bug    
 
quelqu'un sur le forum anglais d'archlinux a aussi le bug :
 

 
https://bbs.archlinux.org/viewtopic [...] 9#p1473209
 
à mon avis ça va monter crescendo au niveau des témoignages lorsque le kernel 3.17 arrivera peu à peu dans les dépôts stables des distributions officiels linux standard, surtout avec la masse des utilisateurs d'ubuntu,
 
ça me rappelle le bug des partitions NTFS ( bug "fuse" dans le kernel 3.16.x ) qui n'apparaissait qu'avec l'utilisation de virtualbox et à condition que la machine virtuelle soit sur une partition NTFS, des conditions très restrictives pour que le bug apparaisse,
 
dans mon cas du freeze aléatoire au boot je pense que c'est la même chose, il faut avoir une configuration matérielle précise ( vieux matos ?  disque branché sur une carte contrôleur IDE/SATA ? un certain type de CPU ? bug de GCC sur des instructions CPU ? )

j'ai remarqué que wine ne fonctionne plus chez moi ( version multilib : wine 1.7.30-1 )
 
j'ai ce message d'erreur quand je veux lancer un programme windows avec wine :
 

 
 
vous avez la même chose ?

Non pas de soucis.

tu as quelle version de wine ?

celui du dépôt multilib ?

tu as lancé un pacman -Syu pour être certain d'être à jour ?

j'ai l'impression que c'est venu depuis la mise à jour de gcc-multilib vers la version 4.9.2-1

Y'en a-t-il un ailleurs que dans multilib

il y a la version i686 de wine si tu n'as pas de cpu x64,

je n'ai pas ce bug avec la version i686 dans une machine virtuelle archlinux i686,

le souci c'est que je n'ai pas d'autres PC 64 bits, donc je ne sais pas si le bug est lié à ma machine, une configuration particulière ou bien s'il se produit avec tous les PC 64 bits,

je commence à en avoir marre de choper des bugs chelous qui n'ont lieu que chez moi

Ah, je suis aussi sous x64.

es-tu sous kde ?
 
j'ai supprimé le dossier  ~/.wine et j'ai toujours le bug,
 
je vais essayer de reconstruire le paquet wine au cas où

et un coup de memtest au cas où j'aurai des barrettes ram défectueuses, qui expliquerait ce bug

sous KDE oui.

tu as bien fait aujourd'hui un pacman -Syu afin qu'on soit sûr qu'on ait les mêmes paquets systèmes ?

Non.

Je suis en testing de toute facon et pas toi donc bon...

je suis en train de reconstruire le paquet wine, j'espère que ça résoudra le problème,
 
sinon ça signifie qu'il y a quelque chose de cassé dans mon installation d'archlinux

Est-ce du au noyau 3.16?
As-tu le meme soucis en 3.17?
(question a tout hasard, mais peut etre que certains paquets dependent du 3.17.. je ne vois pas trop pourquoi mais bon)

j'ai essayé avec le noyau 3.16.4, puis le 3.17.2-1, puis le 3.18rc3,
 
sinon j'ai peut-être une piste : récemment j'ai un peu bricolé mon bios en injectant dans le fichier bios la dernière mise à jour microde d'intel pour mon pentium dual core E6800, j'ai utilisé le programme cbrom en suivant ce tutoriel :
 
http://www.delidded.com/how-to-upd [...] enix-bios/
 
j'ai ensuite flashé le bios avec ce bios modifié, si ça se trouve le bug avec wine vient de là, un mauvais microcode dans le bios ou un bios bogué suite à ma modification,
 
si la reconstruction du paquet wine ne corrige pas le problème alors je vais reflasher mon bios avec le bios d'origine d'avant la modification,
 
je précise que mon autre bug lié au kernel 3.17 ( freeze au boot ) n'est pas lié à ma tentative de modification du bios, car la première fois que j'ai eu le bug ça s'est produit avant que le bios n'ait été flashé

bon j'ai testé avec le paquet wine que j'ai reconstruit --> j'ai toujours le bug
 
j'ai reflashé ensuite le bios avec la version d'origine --> j'ai toujours le bug    
 
wine est le seul programme qui merde dans mon installation, bref je ne comprends pas ce que se passe, si quelqu'un a une idée ?
 
j'ai downgradé aussi le paquet wine jusqu'à la version 1.7.24 et j'ai toujours le bug
 
 
 

Tente un livecd.

à quoi servirait le livecd ?
 
tu parles de quel livecd linux ?
 
wine risque de ne pas être dans le livecd ?
 
une autre solution serait que je me crée une machine virtuelle archlinux 64 bits et que je regarde si wine s'execute bien,
 
là je n'ai qu'une machine virtuelle archlinux 32 bits et quand je teste wine ça se lance bien sans problème sur un binaire windows,
 
il me reste encore la possibilité de créer un utilisateur "test" et de me connecter dessus, comme le home sera tout neuf alors si ça fonctionne ça signifie qu'il y a un fichier de configuration qui merde dans mon home de mon utilisateur habituel

j'ai crée et testé avec un nouveau compte utilisateur --> toujours le même bug

pour l'instant je n'ai eu qu'un seul retour utilisateur : gee avec son installation testing, il faudrait maintenant que quelqu'un qui ne soit pas en testing ( dépôts stables ) puisse me dire si wine se lance aussi sans problème quand on execute un programme windows

Un livecd archlinux.
Avec cela tu pourras tester si c'est ton installation ou pas.
Et effectivement wine ne sera pas dedans de base, mais si tu as assez de RAM tu devrais pouvoir l'installer.

Mais ton idee de VM revient au meme.

je vais tester ça alors    
 

Remarque: avec une VM il est possible que tu tombes sur le meme soucis, si le soucis vient de l'OS de base (type noyau) je me dis que ca peut affecter la VM. De nouveau aucune base pour penser cela, mais ca me parait logique.

bon j'ai testé avec un live CD archlinux ( en réalité une clé USB bootable ), ça bloque car je n'ai que 4 Go de ram, quand j'installe wine au bout d'un moment j'ai un message d'erreur "partition pleine",

de toutes façons ça n'aurait pas marché car il aurait fallu aussi installer un serveur X car si j'execute un programme windows il faudra une session X, pas évident à faire tout ça avec le livecd d'archlinux qui est très basique, il n'y a pas de serveur X installé,

la meilleure option reste donc de créer une machine virtuelle archlinux 64 bits pour savoir pourquoi wine plante sur mon installation archlinux 64 bits actuelle ( installation qui a un an )

l'erreur que j'ai est une erreur liée à glibc ( bibliothèque C standard ) :

s'il y a des pros ici du langage C ils auront peut-être une piste

le backtrace avec winedbg quand je veux executer notepad :

ça donne l'impression que wine a un problème quand il veut créer une interface graphique ( messages liés à  libxcursor.so.1 ), peut-être une incompatibilité avec le pilote radeon open source de ma carte graphique ati radeon HD4650 pcie ?

d'ailleurs quand je lance un programme DOS avec wine là il n'y a pas de plantage, vu qu'un programme DOS n'utilise pas d'interface graphique,

tu as quoi comme carte graphique Gee ?