Vieux geek, épisode 50 : 1997, l’année où la première génération de Pentium devint… folle :)

1997. Microsoft travaille d’arrache-pied sur MS-Windows 97 (qui sera connu sous le nom de MS-Windows 98 au final) et Intel apprend l’existence d’un bug qui fait planter sa génération de processeur grand public haut de gamme, les Pentium et leur pendant amélioré, les Pentium MMX.

En 1994, les processeurs Pentium avaient déjà eu droit à une première « tempête de merde » avec un bug resté dans les mémoires, le bug dit FDIV. En gros, les premiers Pentium qui allait de 66 à 100 Mhz avait un bug affreux, surtout si on avait besoin de faire des calculs en utilisant des nombres décimaux. Les résultats étaient parfois incorrects.

Mais début novembre 1997, c’est un bug d’un autre niveau qui touche les processeurs d’Intel. Le bug dit F00F met le processeur en rideau. En clair, si le processeur était touché par le bug, le seul moyen de récupérer la main était de redemarrer à la sauvage son ordinateur !

Plutôt ennuyeux comme bug. Si Microsoft proposa un contournement pour MS-Windows NT4, sauf erreur de ma part, aucun correctif ne fut proposé avec MS-Windows 95. J’ai pu trouvé une gazette de février 1998 déclarant ceci :

[…]What about Windows 95, Windows 3.1, and Windows NT 3.5x? Microsoft is still making a determination about how to address this bug in all the other Windows operating systems.[…]

Qu’on peut traduire par :

[…]Qu’en est-il de Windows 95, Windows 3.1 et Windows NT 3.5x ? Microsoft est toujours de prendre une décision sur la façon de résoudre ce bogue dans tous les autres systèmes d’exploitation Windows.[… ]

Du Microsoft de la grande époque, non ? Et le logiciel libre, alors ? J’y viens.

Continuer la lecture de « Vieux geek, épisode 50 : 1997, l’année où la première génération de Pentium devint… folle 🙂 »

Quand on a le don de tomber sur des bugs à la c**…

…ça devient ennuyeux. Hier, j’ai enfin pu installer la totalité de Gnome 3.4 sur mon Archlinux via le dépot gnome-unstable.

Je ne vous ferais pas un premier bilan, l’installation est trop fraîche. Cependant, c’est une version de gnome parmi les plus boguées que j’ai eu l’occasion de voir. Et j’ai comme l’impression que la version 3.4.1 de l’environnement sera la bienvenue d’ici quinze jours environ.

Et surement la plus boguée de la série des 3.x. Et pourtant, j’ai commencé à utiliser Gnome 3 une semaine avant la sortie de la version finale de Gnome 3.0, donc autant dire que j’ai de la bouteille avec cette version de l’environnement.

Je ne parlerais pas de la tendance qu’à dhcpcd à se suicider quand il est utilisé en duo avec NetworkManager 0.9.4.0 et qu’on ose avoir une adresse au format IPv6, ni du bug de GnuTLS qui bloque la synchronisation d’un agenda google avec Evolution. Non.

Un bug plus marrant à fait son apparition récemment, et ne se manifeste que quand j’utilise le pilote propriétaire de Nvidia. La capture d’une fenêtre donne un résultat comme si on utilisait un miroir. En gros, ça donne cela :

Bug de gnome screenshot 3.4 ?!

Ayant rapporté le bug chez Gnome, il s’est révélé être le doublon d’un bug déjà connu, d’un composant de Gnome-Shell, cogl.

Quand je disais dans un précédent article que Gnome 3.4, c’était pas gagné, je n’avais pas complètement tort 🙁

Systemd et Archlinux… Quand ça veux pas…

… ça veux pas. J’ai voulu essayer systemd sur ma machine personnelle aujourd’hui. Après avoir suivi le guide d’installation, assez simple soit dit en passant, j’ai redémarré et utilisé mon ordinateur toute la journée sans problème.

Ce soir, après avoir fait ma sauvegarde hebdomadaire sur DVD, j’ai eu besoin de retrouver un document mis de coté sur DVD il y a environ un mois. Et quand je veux insérer le DVD, l’assistant qui détecte le DVD et propose l’ouverture automatique ne pointe pas le bout de son museau.

Qu’à cela ne tienne, j’ouvre nautilus, et je double-clique sur l’icone du DVD… Et je me fais traiter comme du poisson pourri, m’indiquant que le média ne peut être monté. J’en profite au passage pour récolter des infos pour ouvrir un rapport de bug si nécessaire.

Le message d’erreur est étrange :

Error mounting: mount exited with exit code 1: helper failed with:
mount: mount point /media/cdrom does not exist

Décidant de vérifier que c’est bien un bug de systemd, je relance la machine en désactivant systemd, et miracle, l’assistant me propose d’ouvrir ou d’éjecter le DVD fraichement inséré.

Pour en avoir le coeur net, je recommence l’opération en laissant systemd activé, et bien entendu, ça bloque. J’ai donc ouvert un rapport de bug sur l’outil de suivi d’Archlinux. On verra bien si un correctif sera rapidement apporté 🙂

En attendant, et en espérant que le prochain Gnome ne sera pas super dépendant de systemd, je reste avec les vieux scripts de démarrage qui fonctionnent bien 😉

Network Manager a-t-il révélé un méchant bug dans le noyau linux ?

Il y a quelques temps, j’annonçais l’arrivée de Network Manager sur le dépot current de la Frugalware Linux.

Peu de temps après, j’ai été confronté à un bug assez ennuyeux qui se manifestait après une charge réseau un peu lourde ou une grosse opération de calcul : la connexion wifi rendait l’âme.

J’ai donc ouvert un bug, le 4156. Un bug proche existait déjà, et comme un patch était disponible, Miklos Vajna m’a proposé un patch adapté pour recompiler le noyau.

Après une série de galères pour recompiler le noyau, j’y arrive enfin, et manque de chance, le bug est toujours présent, cependant, une ligne m’interpelle et me donne une piste :


net_ratelimit: 10 callbacks suppressed
ath5k phy0: gain calibration timeout (2412MHz)
ath5k phy0: gain calibration timeout (2467MHz)
ath5k phy0: gain calibration timeout (2412MHz)
ath5k phy0: gain calibration timeout (2472MHz)
ath5k phy0: gain calibration timeout (2412MHz)
No probe response from AP 00:1d:6a:9b:6f:a0 after 500ms, disconnecting.

Après quelques recherches, je m’aperçois que cela ne touche pas que mon circuit wifi, mais aussi d’autres, comme ceux de Broadcomm par exemple.

Un contournement sale a été trouvé, via un bug sur le tracker du site kernel.org sur la fiche du bug 15693 : désactiver toute gestion de l’énergie… Et cela semble fonctionner 🙁

Donc, je compte retourner pour le moment à Wicd qui n’utilise pas la connexion wifi quand la connexion filaire est présente.

Ce sera déjà mieux que de désactiver la gestion de l’énergie, non ? 😉