06 août 2012

Linux : suivi du kernel 3.5

Le kernel Linux 3.5 est sorti il y a maintenant 2 à 3 semaines et - congés oblige - je n'ai pas pu vous faire le compte rendu des nouveautés intégrées.

Comme pour mon précédent billet, je vais limiter mon analyse aux nouveautés qui sont importantes pour les cartes que je possède, c'est à dire :

  • Pandaboard ES
  • Rapsberry Pi

A l'avenir, il est tout à fait probable que le range des hardware à ma disposition s'étendent, et donc que le périmètre de mon analyse s'étende avec lui.

Général

Contrairement à ce que j'avais annoncé, OpenWRT ne devrait pas changer sa version de Linux avant un freeze fonctionnel pour sortir la version Attitude Adjustement[1]. Du coup, inutile de s'attendre à une mise à jours vers le kernel 3.5 d'ici un certain temps.

Au niveau du kernel lui-même, l'une des avancées majeure est à mon sens l'intégration de l'algorithme CoDel. Cet algorithme change la manière dont la queue de paquets TCP est traitée, ce qui a un impact très bénéfique sur le problème du bufferbloat. Avec les récentes avancées sur le même sujet de ces derniers mois, on commence à avoir quelque chose de très résistant aux latences réseau, ce qui n'est pas un mal.

Il y a eu d'autres introductions de nouvelles fonctionnalités (uprobes, changements importants en ext4 et brtfs, ...) mais ces changements ont peu d'impact sur le setup classique d'une Pandaboard ou d'une Rapsberry Pi, donc vous ne m'en voudrez pas si je les met de coté.

Spécifique

Logo Pandaboard

Pandaboard / Pandaboard ES

Le support de la Pandaboard (et de sa grande soeur, la Pandaboard ES) s'améliore encore avec cette release. On note toutefois que le patch WLAN est toujours nécessaire. Ce patch n'est pas, à priori, obligatoire pour la Pandaboard ES mais il ne provoque aucun problème, donc il peut être appliqué sans problème.

Au niveau des nouvelles fonctionnalités, rien de neuf : cette version n'introduit aucune révolution. Il y a par contre des changements notables au niveau des drivers.

  • le driver omapdrm supporte maintenant dmabuf.
  • le driver WiFi a été mis à jour et est (semble-t-il) plus stable, mais le bug présent dans les kernels précédents est semble-t-il toujours présent. Les modules wlcore et wl12xx sont maintenant indépendants, ce qui signifie que les deux doivent être sélectionnés pour être construit en tant que modules kernel, et chargé lors de l'initialisation du système. Il semblerait que le wake-on-wan (wow) soit supporté, mais je n'ai pas eu le loisir de le tester (et très honnêtement, je n'en voit pas trop l'intérêt).
  • le support audio sur l'HDMI a enfin été ajouté ; plus besoin de passer par un patch pour avoir quelque chose qui fonctionne correctement.

A la compilation, le nouveau kernel 3.5 devrait vous permettre d'avoir accès à la plupart des fonctionnalités de la Pandaboard. Le bluetooth est censé être complètement supporté (je n'ai pas réussi à le mettre en oeuvre, mais ça ne saurait tarder), ainsi que le WiFi. La gestion du HDMI via le driver drm a été améliorée, mais ce driver ne sert toujours pas de base aux librairies OpenGL fournies par imgtec et TI (il permet tout de même d'avoir du XWindow ou du directfb en résolution HD - avec le son si on passe par la conectique HDMI).

Il est encore nécessaire de passer par l'arbre git de TI - ou de backporter les patches nécessaires - pour avoir accès aux dernières fonctionnalités, comme (notamment) la libdce permettant une communication plus directe entre gstreamer et le chipset Ducati. A noter que la dernière version[2] de OpenBricks (c'est à dire la dernière révision de la branche maître au moment ou je vous parle) offre l'un des meilleurs support Pandaboard du marché : xbmc avec rendu OpenGL (donc très fluide), et playback de vidéo HD avec le son à 30 fps. Je n'ai pas testé le WiFi sur cette plateforme, mais l'ensemble est convaincant.

Logo Rapsberry Pi (couleur, petit)

Rapsberry Pi

Maintenant qu'elle est disponible aisément (rappel : il y a toujours une RPi à gagner sur ce site ; voir le billet A la recherche du thème parfait), de nombreux projets s'étalent sur le web. Certains ont été débuté il y a un certain temps mais n'ont été rendu public que depuis peut de temps.

Dans les projets en cours, on notera le portage de OpenWRT sur RPi, par Ian Ridge. Ce support est en passe d'être intégré à OpenWRT (même si, soyons honnêtes, la RPi n'a rien d'un routeur wireless). Il est important dans le sens où il permet de bénéficier d'un kernel 3.3 sur RPi (la plupart des distributions plus "officielles" utilisent un kernel plus ancien).

Parmi les projets intéressants, notons :

  • La distribution QtonPi, maintenue (à priori) par Nokai. Le but de cette distribution est de proposer un environnement QT Embedded sur la RPi.
  • rapsbmc, une distribution basée sur Debian et XBMC, actuellement en -rc4.

Au niveau du support kernel spécifique de la RPi ajouté dans le kernel 3.5, je suis au regret de vous dire qu'il n'est pas excessif[3]. Pour l'instant, le développement kernel de la RPi est au mieux chaotique (les patches sont produits ici et là, et rarement remontés upstream). Les deux kernels connus les "mieux" maintenus sont celui de Chris Boot (bootc) (mais bootc ne supporte que le kernel 3.2.x) et celui de Simon Arlott, avec un support du kernel 3.4-rc5. Aucun de ces deux arbres n'a été mis à jour récemment, mais bootc continue de maintenir son blog parlant principalement de RPi.

Le kernel "officiel", maintenu sur github est un kernel 3.1.9. Il a été importé le 12 janvier 2012 sur github, et contient certains patches backportés de la 3.2. Le nombre de patches appliqués à cet arbre est relativement faible, ils devraient donc être possible de porter les patches nécessaires vers un kernel 3.5, voire de faire l'effort nécessaire à les intégrer à la mainline du kernel Linux (un tel effort de rationalisation n'a pas été mis en oeuvre pour l'instant).

Au final, les problèmes suivants sont connus :

  • crash fréquents sur le contrôleur USB ;
  • instabilités lorsque la carte SD et le driver réseau sont utilisés au même moment ;

Il s'agit des problèmes les plus grâves, pour lesquels seules des solutions partielles existent.

Notes

[1] cf. le mail de John Crispin sur la mailing list openwrt-devel

[2] révision 81db4cf96d1e sur l'arbre Mercurial

[3] et je dis ça parce que je suis insatiable dans ma poursuite de l'euphémisme parfait

Commentaires

1. Le vendredi, août 24 2012, 21:39 par alpha_one_x86

Une messure de consomation des 2 cartes aurai été top.

Sur mon Rapsberry Pi en routeur (base conso), et donc passerelle, j'ai des crash noyaux car il y as une merde dans la gestion des interuptions avec 2 carte réseau en passerelle.
Je veux aussi CoDel pour la même raison.

2. Le lundi, août 27 2012, 18:07 par Emmanuel Deloget

CoDel ne va pas aider si c'est un problème d'IRQ :) (ok, je sais que tu sais).

Si tu peux poster les traces kernel, je peux peut-être aider. J'ai du mal à comprendre comment tu peux avoir deux sorties réseau sur la RPi (à moins que tu n'ais mis une carte réseau usb, ce qui ne devrait normalement pas te poser de problèmes, les deux sous-systèmes étant bien séparés).

Je suis complètement d'accord pour faire une mesure de consommation ; ceci dit, je sais d'avance que la RPi va gagner - le chipset broadcom utilisé étant moins gourmand que l'Omap 4, et le nombre de périphérique sur la RPi étant moins nombreux que sur la PB ES. Lorsque je trouverais un moyen de faire cette mesure (ce qui est loin d'être sûr), je ferais une mise à jour sur le sujet.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet