English version
Présentation du problème
Depuis que je suis passé à Mac OS X Lion sur mon MBP 15″ mid-2009, j’ai rencontré plusieurs Kernel Panic, beaucoup trop à mon goût. Pour ceux qui ne le savent pas, sous Mac OS, un Kernel Panic se présente sous cette forme :
« L’équivalent » d’un BSoD sous Mac OS X
Ces Kernel Panic apparaissaient de manière aléatoire, sans lien avec mon activité du moment. J’en ai eu jusqu’à un par jour, ce qui peut être vraiment embêtant au bout d’un moment. Ces Kernel Panic ont persisté (voir empiré) après la mise à jour 10.7.2 d’il y a quelques jours.
Après enquête il se trouve que ces Kernel Panic étaient provoqués par une extension du noyau de Mac OS X (kernel extension — kext) dont la signature était com.cisco.nke.ipsec (2.0.1). Comment savoir si c’est votre cas ? C’est assez simple : après le Kernel Panic, vous redémarrez votre ordinateur. Une fois redémarré il vous signale que cet ordinateur a été éteint à cause d’un problème et vous propose d’envoyer un rapport d’erreur à Apple : demandez à voir des détails et examinez le rapport d’erreur. Si c’est bien cette extension de noyau qui est responsable, vous devriez voir quelque chose comme :
Interval Since Last Panic Report: 26005 sec
Panics Since Last Report: 1
Anonymous UUID: 8C7D8BB2-0000-0000-0000-3409CFA30000
Thu Oct 6 12:58:34 2011
panic(cpu 0 caller 0x2bc59c): Preemption level underflow, possible cause unlocking an unlocked mutex or spinlock
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
0x585db2f8 : 0x22032e (0x6ac0fc 0x585db318 0x229ef0 0x0)
0x585db328 : 0x2bc59c (0x801146 0x86a3eb0 0x0 0x8587300)
...
0x585dbf88 : 0x354132 (0x0 0x53ef6d00 0x0 0x8d8ef58)
0x585dbfc8 : 0x2c5d0c (0x8d8ef2c 0x0 0x2c5d1b 0x841d000)
Kernel Extensions in backtrace:
com.cisco.nke.ipsec(2.0.1)[00000000-0000-0000-0000-000000000000]@0x81f36000->0x81faafff
BSD process name corresponding to current thread: kernel_task
Boot args: arch=i386
Mac OS version:
11B26
Kernel version:
Darwin Kernel Version 11.1.0: Tue Jul 26 16:09:02 PDT 2011; root:xnu-1699.22.81~1/RELEASE_I386
Kernel UUID: D5E41653-0000-0000-0000-4C2E20020000
System model name: MacBookPro5,3 (Mac-F22587C8)
System uptime in nanoseconds: 13333138736372
last loaded kext at 13240839389556: com.apple.iokit.IOAVBFamily 1.0.0d22 (addr 0x59a1f000, size 32768)
last unloaded kext at 13205522356367: com.apple.iokit.IOEthernetAVBController 1.0.0d5 (addr 0x1fcb000, size 20480)
loaded kexts:
com.cisco.nke.ipsec 2.0.1
org.virtualbox.kext.VBoxNetAdp 4.0.12
org.virtualbox.kext.VBoxNetFlt 4.0.12
org.virtualbox.kext.VBoxUSB 4.0.12
...
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0237, 0x04600000 / 3
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x04500000 / 2
Ce qui est important ici, c’est la ligne 16 : elle vous indique que c’est bien com.cisco.nke.ipsec (2.0.1) qui est à l’origine du Kernel Panic. Notez que ces rapports sont aussi disponibles à travers l’application Console (/Applications/Utilitaires/Console) : vous pouvez alors vérifier que vos précédents Kernel Panic ont aussi été causés par cette extension.
Alors, cette extension, elle sert à quoi ? Elle sert à se connecter à des systèmes VPN Cisco. Moi j’en avais besoin pour le VPN de mon ancienne université1. C’est un problème si vous en avez toujours besoin. Attention, même des logiciels tiers, tels que Shimo, utilisent cette extension, pas seulement le client officiel Cisco. C’est pour cette raison que la méthode de résolution que je présente ne supprime pas l’extension, elle vous permet juste de l’activer quand vous le voulez.
Résolution
Dans un premier temps, il faut que vous vérifiez que l’extension est bien chargée dans votre système. Pour ça, ouvrez un terminal (/Applications/Utilitaires/Terminal ou l’application iTerm que je préfère) et tapez la commande suivante :
$ sudo kextstat
Puis tapez votre mot de passe administrateur. Si vous voyez notre extension com.cisco.nke.ipsec (2.0.1) c’est bon, vous pouvez continuer. Désactivez l’extension grâce à la commande :
$ sudo kextunload /System/Library/Extensions/CiscoVPN.kext
Vous pouvez dès à présent vérifier que l’extension n’est plus chargée grâce à la commande kextstat.
Il faut maintenant désactiver le chargement automatique de l’extension au démarrage. Pour ça il faut déplacer deux éléments. Stockez-les à un endroit où vous êtes sûrs de les retrouver2. Personnellement, j’ai choisi ~/Documents/Informatique mais vous faites comme vous voulez. Exécutez donc les commandes suivantes :
$ sudo mv /System/Library/Extensions/CiscoVPN.kext ~/Documents/Informatique/ $ sudo mv /System/Library/StartupItems/CiscoVPN ~/Documents/Informatique/
Faites attention à bien conserver les droits sur ces deux éléments, sinon vous ne pourrez pas réactiver l’extension par la suite.
Voilà ! L’extension est désactivée et ne se chargera plus au démarrage !
Réactivation de l’extension
Si vous avez besoin de vous connecter à un VPN Cisco, vous avez besoin de réactiver cette extension. Pour ça, une commande :
$ sudo kextload /path/to/kext/CiscoVPN.kext
Si vous n’avez pas les bons droits sur cet élément, vous allez obtenir cette erreur :
/path/to/kext/CiscoVPN.kext failed to load - (libkern/kext) not privileged; ... ... check the system/kernel logs for errors or try kextutil(8).
Les bons droits sont les suivants :
$ ls -l total 10159200 drwxr-xr-x 5 root wheel 170 23 aoû 2010 CiscoVPN drwxr-xr-x 3 root wheel 102 23 aoû 2010 CiscoVPN.kext
Pour manipuler droits, permissions, propriétaire et groupe, utilisez les outils chmod et chown.
À partir de maintenant, vous devriez pouvoir voir l’extension com.cisco.nke.ipsec (2.0.1) dans la liste fournie par la commande kextstat. N’oubliez pas de la désactiver une fois votre travail fini sur votre VPN Cisco :
$ sudo kextunload /path/to/kext/CiscoVPN.kext
Un peu de lecture
Si ces histoires d’extensions de noyau vous intéressent, je vous propose ce site, et plus particulièrement cette page qui liste un grand nombre d’outils d’utilisation poussée de Mac OS X.

If my Mac had made such a weird decision as swapping <time> for <data> it would at least have the good grace to kernel panic afterwards.