Introduction

Depuis presque un an et demi que je possède un Raspberry Pi, j’ai rencontré tout un tas de crashs inopinés de la bête au fur et à mesure des installations softwares et hardwares.

Vous trouverez ci-dessous quelques astuces qui vous permettront de résoudre ou de contourner les problèmes.

Causes de crashs

Carte SD

Le choix de la carte SD ou Micro-SD pour votre Raspberry Pi est TRES important.

Le site ci-dessous référence toute une série de cartes et indique leur compatibilité avec le Pi :
http://elinux.org/RPi_SD_cards

Préférez acheter une carte authentique de marque connue dans une enseigne réputée plutôt que d’en acheter une, peut-être contrefaite, sur eBay ou AliExpress.

Ce blog donne quelques exemples : http://blogmotion.fr/diy/carte-sd-rpi-12174

Dans la même veine, je suis récemment tombé sur un article expliquant que les constructeurs de smartphones Androïd commençaient à supprimer le port SD de leurs appareils car les utilisateurs y insèrent des cartes bas de gamme et les incriminent ensuite quand les problèmes de corruption des données surviennent.

http://www.phonandroid.com/hugo-barra-explique-pourquoi-xiaomi-pas-port-microsd-smartphones.html

Alimentation

Le choix

Là encore, il convient de bien choisir son alimentation.

Bien que le Raspberry Pi se contente d’une puissance allant de 1W à 3,5W en fonction du modèle, il ne faudra pas hésite à choisir une alimentation légèrement surdimensionnée qui permettra de brancher quelques périphériques USB sans nuire au bon fonctionnement de la carte.

On évitera tout ce qui est chargeur GSM/Smartphone qui ne délivrent généralement que 500mA.

Et là aussi, les chinoiseries sont à proscrire. Il vaudra mieux investir quelques euros de plus dans une alimentation sérieuse plutôt que de voir son Pi planter régulièrement parce que le transfo n’est pas capable de maintenir une tension constante de 5V.

Dans cette vidéo Youtube, le gars explique comment mesurer la tension du Raspberry Pi en charge (en fonctionnement) :

La mesure s’effectue entre TP1 (+) et TP2 (-) :

Référence : http://raspbian-france.fr/accessoires-raspberry-pi-2/

Power feedback

J’avais un petit souci de retour d’alimentation dans le Raspberry Pi par les connecteurs USB A.

En effet, mon disque dur externe, qui possède sa propre alimentation 5V, demandait un ordre d’allumage précis pour fonctionner correctement (cfr. article).

De même, je le suspectais de provoquer des variations de tension sur le Pi lors de ses démarrages en sortie de veille.

En suivant les conseils de cet article (http://stevenhickson.blogspot.be), j’ai recouvert la broche + de la fiche USB pour résoudre le problème.

La broche + se trouve à droite lorsque l’on regarde la fiche de face :

On découpe un petit morceau de tape isolant selon les dimensions reprises sur l’image ci-dessous :

Et on le colle de manière à recouvrir complètement la broche jusqu’au fond de la fiche :

Attention :

J’ai effectué la même opération sur un HUB USB qui présentait le même problème et ça a fonctionné.

Par contre sur un autre HUB USB qui ne présentait pas de « power feedback », ça n’a pas fonctionné. Il n’était même plus reconnu par l’OS.
En effet, le périphérique étant électriquement bien séparé entre USB in et USB out, la partie amont devait être alimentée par le Pi pour fonctionner alors que la partie aval recevait son énergie du transfo.

SeedBox

Transmission

Lorsque l’on possède un Raspberry Pi, il est tentant d’y installer Transmission et, ainsi, le transformer en SeedBox qui partagera des fichiers Torrents 24/7.

Si, comme moi, vous partagez tout un tas de distributions Linux qui génèrent un trafic constant important, vous risquez de voir votre Pi se planter tous les 3 ou 4 jours.

En cause, un problème de gestion de la mémoire que l’on pourra résoudre comme expliqué ci-dessous.

smsc95xx

Le pilote réseau du RPi peut parfois avoir du mal à gérer un trafic intense sur les ports USB et le port Ethernet, surtout en cas d’utilisation importante du processeur. Il peut ainsi perdre la trace de connexions et, dans certains cas, saturer la mémoire et crasher.

Pour résoudre ces problèmes on utilisera ces méthodes :

• Réserver un minimum de mémoire libre
• Désactiver le mode « Turbo Réseau »
• Gérer les Torrents

Résolution des problèmes

Mémoire

Les crashs système sur le Raspberry Pi proviennent souvent d’une mauvaise gestion de la mémoire vive.

La commande free peut nous donner un aperçu de sa répartition :

$ free -h

Le paramètre -h permet d’afficher les données selon l’unité la plus concise pour la lecture humaine.

$ free -h
             total       used       free     shared    buffers     cached
Mem:          974M       492M       482M         0B        25M       241M
-/+ buffers/cache:       224M       750M
Swap:          99M         0B        99M

• Total: Le total de la mémoire utilisable (1Go ou 512Mo) auquel on a soustrait une partie réservée au processeur graphique.
• Used: L’ensemble de la mémoire utilisée qui comprend la partie les programmes et processus en cours d’exécution ainsi que le buffer et la mémoire cache.
• Free: La mémoire totalement disponible.
• Shared: man free indique que shared peut être ignoré car d’utilisation obsolète.
• Buffers: Une mémoire utilisée pour entreposer temporairement des données, notamment entre deux processus ou matériels ne travaillant pas au même rythme.
• Cached: Une partie de la mémoire dans laquelle persistent des programmes ou processus chargés précédemment. Il ne sont pas supprimés tant qu’il reste suffisamment de mémoire libre. Ceci évite de recharger à chaque fois en mémoire des programmes souvent utilisés.

Dans certains cas, notamment lors de l’utilisation de Transmission, si la taille du cache utilise presque toute la mémoire vive et que de la mémoire libre est rapidement nécessaire, il est possible que le kernel se crash.

Libération manuelle de la mémoire cache

Il est possible de libérer manuellement de la mémoire cache pour retrouver de la mémoire libre (si le noyau Linux est plus récent que le 2.6.16) en procédant comme suit :

• Libérer pagecache:

  $ echo 1 > /proc/sys/vm/drop_caches

• Libérer dentries and inodes:

  $ echo 2 > /proc/sys/vm/drop_caches

• Libérer pagecache, dentries and inodes:

  $ echo 3 > /proc/sys/vm/drop_caches

Les commandes précédentes doivent être exécutées en tant que root (su). Si vous voulez les exécuter en sudo, vous devez utiliser cette syntaxe :

$ sudo sh -c 'echo 1 >/proc/sys/vm/drop_caches'
$ sudo sh -c 'echo 2 >/proc/sys/vm/drop_caches'
$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'

Le résultat après avoir envoyé « 3 » dans drop_caches :

             total       used       free     shared    buffers     cached
Mem:          974M       326M       648M         0B       1,3M       103M
-/+ buffers/cache:       221M       753M
Swap:          99M         0B        99M

On peut décider de vider la mémoire cache (par exemple toutes les heures) en incluant l’une des commandes ci-dessus dans le cron.

Source : https://unix.stackexchange.com

Réserver un minimum de mémoire libre

Afin d’empêcher la mémoire cache de trop empiéter sur la mémoire libre et de la réduire à peau de chagrin, il est possible de définir la taille minimum de cette dernière.

On édite le fichier sysctl.conf :

$ sudo nano /etc/sysctl.conf

Et on modifier la ligne :

vm.min_free_kbytes = 8192

En :

vm.min_free_kbytes = 32768

Et on relance :

sudo sysctl -p

Les valeurs sont données en ko. On passe ici de 8Mo à 32Mo.

Source : http://stevenhickson.blogspot.be

Désactiver le mode « Turbo Réseau »

On peut rencontrer cette erreur dans les fichier de log suivant :

smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

• /var/log/messages
• /var/log/kernel
• /var/log/dmesg

L’erreur ci-dessus peut être évitée en demandant au noyau de désactiver le mode « Turbo Réseau ».

Pour ce faire, nous allons editer le fichier /boot/cmdline.txt :

$ sudo nano /boot/cmdline.txt

Et y ajouter ce bout de code à la fin de la ligne :

smsc95xx.turbo_mode=N

Ce qui pourrait donner quelque chose comme ceci :

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait smsc95xx.turbo_mode=N

Source : https://raspberrypi.stackexchange.com

Gérer les Torrents

Le principe est de limiter la vitesse de téléchargement et le nombre de Torrents simultanés.

On va éditer le fichier de configuration de Transmission :

$ sudo nano /etc/transmission-daemon/settings.json

Et on va modifier les entrées suivantes comme ceci :

"peer-limit-global": 80,
"peer-limit-per-torrent": 20,

"speed-limit-down": 500,
"speed-limit-down-enabled": true,
"speed-limit-up": 10,
"speed-limit-up-enabled": true,

Ces valeurs sont très basses et il conviendra de les adapter à votre usage.

Sources : https://www.fanjoe.be