Informatique

Problème de compilation avec le nouveau pilote NVIDIA

Sunday, 17 April 2011
|
Écrit par
Grégory Soutadé

En retard (comme d'habitude), j'ai mis à jour hier ma Debian Wheezy (testing). Je vois dans la liste qu'il y a un nouveau noyau (le 2.6.38), donc c'est une mise à jour périlleuse pour les périphériques qui ne sont pas directement supportés par le noyau, à savoir : le pilote rtl8192e pour le Wifi et le pilote NVIDIA GeForce 330M pour la carte graphique.

Généralement tout se passe bien, enfin généralement... Pour le wifi c'était OK (il suffit de recompiler les pilotes), mais pour la carte graphique, le serveur X ne voulait plus se lancer. C'est un problème fréquent, on retourne via l'ancien noyau sur le site de NVIDIA, on télécharge le nouveau pilote et les headers du noyau puis on redémarre pour le compiler.

Comme d'hab il y a la vérification de gcc qui se règle en préfixant la commande par CC="gcc-4.4", mais cette fois-ci la compilation échoue ! On va voir ce qui se passe dans /var/log/nvidia-installer.log :

kernel/nv.c:426: error: unknown field ‘ioctl’ specified in initializer

C'est la première fois que ça arrive. Ni une, ni deux, j'extraie les sources de NVIDIA-Linux-x86_64-256.53.run avec

./NVIDIA-Linux-x86_64-256.53.run -x

j'ouvre le fichier nv.c, tout semble correct. Sauf qu'en fait le champs ioctl de la structure file_operations a été supprimé depuis 6 mois à cause du BKL (Big Kernel Lock). Arf les bougres ! La modification à réaliser n'est pas compliquée :

--- a/NVIDIA-Linux-x86_64-256.53/kernel/nv.c 2011-04-17 10:22:22.861937886 +0200 +++ b/NVIDIA-Linux-x86_64-256.53/kernel/nv.c 2011-04-17 09:08:21.000000000 +0200 @@ -423,9 +423,10 @@ static struct file_operations nv_fops = { .owner = THIS_MODULE, .poll = nv_kern_poll, - .ioctl = nv_kern_ioctl, #if defined(HAVE_UNLOCKED_IOCTL) .unlocked_ioctl = nv_kern_unlocked_ioctl, +#else + .ioctl = nv_kern_ioctl, #endif #if defined(NVCPU_X86_64) && defined(HAVE_COMPAT_IOCTL) .compat_ioctl = nv_kern_compat_ioctl,

On déplace le champs ioctl dans un #else. On recompile et ça tourne ! Même binaire, les pilotes NVIDIA sont de très bonne qualité, c'est bizarre d'avoir laissé une telle erreur. Je viens de leur envoyer un message (dur de trouver un point d'entrée), j'espère que ce sera corrigé dans la prochaine version.

SSII Le jeu

Saturday, 16 April 2011
|
Écrit par
Grégory Soutadé

"Bonjour, j'en prendrai pour 400 kilos s'il vous plaît."
"Bien sûr et avec ça ?"
"Ce sera tout, merci."

C'est la caricature classique d'une SSII (Société de Service en Ingénierie Informatique), société d'intérim de luxe qui vend la compétence que personne (à part les informaticiens) ne possède pour réaliser un projet informatique. Ce sont des super Manpower que l'on ramène souvent à des marchands de viande, oui mais de la bonne môssieur, et qui coûte cher (plusieurs centaines d'euros par jour pour un ingénieur). C'est là aussi qu'on retrouve le fameux duel maître-esclave commercial-informaticien. Personnellement j'ai, pour l'instant, la chance d'échapper à ce système qui représente une très grande partie des emplois en informatique en France (surtout en région PACA).

SSI Le jeu

Bref, au-delà de ces basses diffamations Google m'a proposé un lien sponsorisé depuis GMail vers le site SSII Le jeu qui est une simulation de SSII. C'est-à-dire que vous êtes placé dans la peau d'un directeur qui doit chercher des partenaires (salariés ou freelance) et répondre à des marchés (propals) pour placer ses collaborateurs. Naturellement le but du jeu est d'avoir la plus grosse (SSII), donc le plus d'informaticiens, le plus gros chiffre d'affaire, le plus gros bénéfice ...

L'aspect esthétique laisse un peu à désirer (c'est surtout une vitrine développés par AGSI pour ses sites freelance-info.fr et carriere-info.fr), mais comme dans tout jeux de simulation on prend rapidement goût aux quelques chiffres inscrits dans la base de données du site. Il est conseillé d'utiliser AdBlock pour limiter l'excès de pub du site. Pour pimenter le tout on peut introduire notre petite PME/SSII en bourse (mais gare aux OPA !!). Vu certains chiffres (plusieurs milliers d'informaticiens pour certaines SSII) ça ne m'étonnerait pas qu'elles soient contrôlées par un robot (ce qui n'est pas interdit par les CGU), d'ailleurs il y a pas mal de plaintes sur le forum (surtout concernant l'entrée en bourse).

Comme pour Friends For Sale (Facebook), le concept de vendre des humains pour faire des sous est assez sympa, même si on en a vite fait le tour. J'ai créé la SSII Clooney (je n'avais que ce nom en tête ...) et pour ceux qui veulent faire un petit geste mon numéro de parrain est le 32817, mais ce qui est intéressant avant tout c'est d'avoir pleins de joueurs pour rendre le jeu un peu plus vivant (même si on a l'impression qu'il n'évolue plus depuis longtemps, il a été crée en 2006), un passage à l'open source redonnerait sûrement un coup de jeune au jeu. L'inscription est rapide et sans douleur, un nom de SSII et un mail suffit.

Focus sur le SheevaPlug

Sunday, 20 March 2011
|
Écrit par
Grégory Soutadé

Présentation

Un petit article pour présenter plus généralement le SheevaPlug. En effet les articles précédents se sont focalisés sur l'utilité d'un serveur de manière générale, mais il y a pas mal de questions sur le SheevaPlug en lui même. Le SheevaPlug c'est donc cette petite bête :


Il comporte (pour simplifier) :

  • Une mémoire interne (flash) de 512Mo
  • Une mémoire vive de 512Mo
  • Un processeur ARM de 1Ghz.

C'est l'équivalent d'une configuration de PC d'il y a 7 ans à peu près A défaut que celui-ci ne consomme que 5 Watts, ce qui est largement inférieur à n'importe quel PC, même basse consommation. Avec si peu de puissance il est évident qu'on ne peut pas faire tourner Crysis dessus, et c'est normal car sa fonction principale est d'être un serveur.

Un serveur c'est une machine qui va répondre à des requêtes externes pour, par exemple, servir des pages web, échanger des mails, stocker des données, et pour tout cela, point besoin de puissance. Personnellement je l'utilise, entre autre, pour faire de la compilation (voir ici un petit bench) automatique de KissCount, avoir un serveur SSH, un serveur mail, héberger mon blog, héberger une forge logicielle, accèder à mes comptes. Pour information la compilation de KissCount prend 15 minutes par version/architecture (soit 1h en tout) contre 1 minutes sur un PC de dernière génération. Elle est réalisée à 1h du matin pour ne pas peturber les autres services.

A l'intérieur du Sheeva


Concernant le système d'exploitation, le SheevaPlug est livré avec une Ubuntu toute prête. En effet on est sur un processeur ARM, donc Linux est tout choisi pour faire fonctionner le système. Bien sûr on aurait pu prendre un BSD, mais le portage n'est pas top, voir même un eCos si certains ont du temps ... MacOS on oublie tout de suite et les seuls Windows qui supportent ARM sont WindowsCE et WindowsPhone 7, mais là encore rien n'est fait pour les acceuillir. Avec Ubuntu on dispose de toute la logithèque GNU/Linux !

De plus le Sheeva ne possède pas d'écran et aucun connecteur pour en brancher un. Ce n'est évidement pas un problème car dans le monde GNU/Linux on peut parfaitement administrer une machine en ligne de commande via SSH (console à distance) en téléchargeant les logiciels et en éditant les fichiers de configuration via un éditeur en mode texte (nano, vi, emacs ...). mais une fois les bon paquets on peut aussi faire l'administration courante via des interfaces web. Les plus téméraires pourront installer un environnement graphique et/ou faire un affichage déporté via SSH, mais c'est complètement inutile et consommateur de ressources.

MAJ : NewIT propose quand même des écrans tactiles via USB (moniteurs MIMO)

Pour les bidouilleurs il faudra de toutes façons passer au moins par la sortie série (en micro USB) du Sheeva afin de modifier la séquence de lancement pour pouvoir booter sur un périphérique autre que la flash ou la carte SD. C'est très pratique pour récupérer la main sur le système quand celui-ci est cassé (comme décrit dans ce billet lorsque le SheevaPlug ne démarre plus).

512Mo de flash c'est suffisant pour le système d'exploitation, mais on se retrouve vite limité. Personnellement j'ai opté pour installer une Debian sur une clé USB 16Go, et tant qu'on ne veut pas stocker sa collection de DivX, c'est largement suffisant ! Il faut cependant faire attention avec ce port USB. Si le périphérique que vous branchez ne possède pas sa propre alimentation, le courant va être récupéré depuis le SheevaPlug, ce qui peut causer des dégâts si la demande est trop importante. Donc pour une clé USB ça passe, mais si vous branchez un disque dur ou un hub il faut faire attention à ce que ceux-ci possèdent leurs propre alimentation !!

Il y a un port eSata sur la version que j'ai acheté, mais je ne l'ai jamais utilisé, je suppose que le problème d'alimentation est le même.

Bref je possède le SheevaPlug depuis 8 mois et je n'ai eu aucun problème, une fois configuré on l'oublie, il ne chauffe pas et me permet d'héberger mes propres services sans soucis (il ne faut pas oublier de faire des sauvegardes régulières). Je ne voulais pas prendre de GuruPlug car il n'est pas plus puissant mais consomme plus à cause du Wifi et du Bluetooth. Il est aussi réputé pour des problèmes d'alimentation. Le double ethernet est bien si on veut faire une passerelle ou un pare-feu.

Le prix

La première année : 130€ chez NewIt + 4€ pour le nom de domaine (certificat SSL offert) + 5€ pour l'électricité. Donc 139€/an soit 11,58€/mois
A partir de la seconde année : 7€ pour un nom de domaine OVH + 15€ pour un certificat SSL + 5€ pour l'électricité. Donc 27€/an soit 2,25€/mois

C'est donc tout à fait raisonable (surtout à partir d'un an). On avait annoncé une baisse rapide du prix de ces joujous, mais je ne pense pas que ça arrivera un jour car les quantités vendues sont trop faibles.

Conclusion

En conclusion le SheevaPlug est l'appareil parfait pour tout ceux qui veulent un petit serveur chez eux ou se lancer dans de l'auto-hébergement !

conversion ISO-8859-1 vers UTF-8 avec iconv

Tuesday, 22 February 2011
|
Écrit par
Grégory Soutadé

Après m'être battu un moment avec iconv, voici un petit exemple de conversion ISO-8859-1 vers UTF-8 :

#include ‹iconv.h› int translate_text(char** text, char free_text) { char* tmp_in, *tmp_out, *original_out; size_t mult_size, size_in, size_out; if (!text || !*text) return 1; converter = iconv_open ("UTF-8", "ISO-8859-1"); if (converter <= 0) return 1; size_in = strlen(*text); mult_size = size_out = size_in*4; // Because UTF8 is bigger thant ISO-XXX tmp_in = *text; original_out = tmp_out = malloc(size_out); iconv(converter, &tmp_in, &size_in, &tmp_out, &size_out); // All variables are modified by iconv original_out[mult_size-size_out] = 0; if (free_text) free(*text); *text = original_out; iconv_close(converter); return 0; }

Compilation croisée sur SheevaPlug

Wednesday, 26 January 2011
|
Écrit par
Grégory Soutadé

Dans mon article précédent je faisais une petite comparaison entre le SheevaPlug et un DELL OptiPlex quasi dernière génération. Voilà un petit retour d'expérience sur la compilation croisée depuis le Sheeva.

Pour rappel : la compilation croisée c'est compiler depuis un plateforme matérielle/logicielle A pour créer des binaires qui s'exécuteront sur une plateforme matérielle/logicielle B. Exemple : on compile sur une plateforme ARM pour une plateforme x86, ou encore une plateforme x86 64 bits vers x86 32 bits.

1) Récupérer crosstool-ng

Jusque là pas de problème, il s'installe facilement et est multi-plateforme (ce n'est que du script bash).

2) Compilation de la toolchain

La ça coince un peu plus, comme indiqué précédement j'ai eu des problèmes avec la eglibc, mais ça s'est résolu en modifiant une config d'exemple. J'ai compilé deux toolchains : une en 32 bits (i686-nptl-linux-gnu) et une en 64 bits (x86_64-nptl-linux-gnu).

3) Compilation du logiciel

Pour un simple "Hello World !" il n'y a pas de soucis, mais dès qu'on commence à construire un logiciel un peu plus costaud on a rapidement quelques ennuis.


Tout d'abord il faut préparer le Makefile à la cross compilation pour supporter la définition externe des variables type CXXFLAGS ou LDFLAGS. Cela consiste à remplacer CXXFLAGS="Quelque chose" par CXXFLAGS+="Quelque chose", idem pour LDFLAGS. Il faut aussi changer CXX=g++ en CXX=$(HOST)g++.

Les modifications pour KissCount sont dans ce commit.


Second problème : les bibliothèques externes type GTK ou dans mon cas wxWidgets. Là il faut ruser un peu plus, on ne peut pas installer directement le runtime car le paquet est compilé pour une architecture ARM donc ld ne va pas s'y retrouver. A moins de passer une option pour ignorer les différences d'architecture, mais je n'ai pas testé, et surtout je ne voulais pas installer ce paquet avec toutes ses dépendances (GTK, Xorg, ...) sur le serveur. J'ai donc importé à la fois les entêtes (headers) et les bibliothèques (.so) dans les dossiers include_wxwidgets_32 et lib_wxwidgets_32 (idem pour la version 64 bits) depuis une machine où ces paquets sont installés.


Dans le Makefile on fait appel à wx-config pour récupérer les valeurs de LDFLAGS et CXXFLAGS, j'ai donc crée un faux wx-config qui va renvoyer le chemin de include_wxwidgets_32 et lib_wxwidgets_32. Ensuite on définit HOST avec "i686-nptl-linux-gnu-" ou "x86_64-nptl-linux-gnu-", puis on déroute PATH vers ~/x-tools/i686-nptl-linux-gnu/bin:.:$PATH (le "." est l'endroit où il y a le wx-config). Enfin on lance LDFLAGS="-Wl,--allow-shlib-undefined" make. L'option "allow-shlib-undefined" permet de ne pas faire une résolution récursive des symbols dans les bibliothèques partagées, ainsi on n'a pas besoin de copier tout GTK pour pouvoir lier notre programme avec wxWidgets (qui dépend GTK).


La compilation se passe bien ... en 32 bits ! On peut même exécuter le programme sans problème sur une autre machine. Mais en 64 bits ça coince lors de l'édition de lien finale avec les erreurs suivante :

undefined reference to `__libc_csu_init'
undefined reference to `__libc_csu_fini'

Cela vient du fait que la libc 32 bits (de la plateforme de compilation) ne définit pas ces symbols et le compilateur (même 64 bits) utilise la libc de l'hôte. Personnellement j'ai fait deux liens symboliques :

ln -s /lib64     ~/x-tools/x86_64-nptl-linux-gnu/x86_64-nptl-linux-gnu/sys-root/lib/
ln -s /usr/lib64 ~/x-tools/x86_64-nptl-linux-gnu/x86_64-nptl-linux-gnu/sys-root/usr/lib/

On met à jour LDFLAGS dans le Makefile avec -L/lib64 et -L/usr/lib64 et le tour est joué !

4) Compilation automatique (Nightly build)

Pour courronner le tout, j'ai fait un petit script qui va s'exécuter chaque nuit (via crontab), vérifier depuis le dépôt git s'il n'y a pas une nouvelle version pour chaque branche et si c'est le cas, la compiler pour chaque architecture ! Il suffit alors de feinter inDefero en utilisant un liens symbolique "Nightly_Build_${branche}_${ARCH}.tar.bz2" pour rendre la nouvelle version disponible. De plus le script envoie un mail en cas d'echec ou de réussite (que demander de plus ??).

Ma hierarchie de dossier est la suivante :

/KissCount
|-- lib_wxwidgets_32/
|-- include_wxwidgets_32/
|-- lib_wxwidgets_64/
|-- include_wxwidgets_64/
|-- wx-config
|-- mega_compile.sh
|-- lib_i686/                  # Spécifique KissCount
|-- lib_x86_64/            # Spécifique KissCount
|-- kisscount_master/
|-- kisscount_dev/


Attention : lors du clone du dépôt git, il faut cloner un dépôt public, sinon il demande le mot de passe pour faire un pull.

Mon script de compilation mega_compile.sh

Et dans /etc/crontab :

0  2    * * *  www-data cd /KissCount && ./mega_compile.sh > /dev/null