A priori OSS n’est pas installé, seul le paquet alsa-oss l’est. Il me sort le même code d’erreur. Avant de désinstaller le noyau 3.2, j’ai booté sous ce noyau et le son fonctionnait.
Dans le cas où le driver d’un périphérique n’est pas présent. est-ce-que le lspci pourra afficher ses informations ?
lspci liste le matériel connecté au bus pci, et ne s’occupe pas du driver.
L’option nn permet d’avoir identifiant complet (fabricant et produit)
Avec ces infos, tu as des sites qui te permettent de connaitre le driver requis.
et ensuite, il faut vérifier si ce driver est bien activé (lsmod)
Merci pour votre aide jusqu’ici, mais je ne vois pas ce qui peut se passer. Ça ne peut pas être un bug du noyau 3.16 car on en aurait entendu parler. Vous avez une idée ?
J’ai cherché un peu comment trouver si il y a 2 modules en conflit (et surtout, lequel!), mais pour l’instant, je n’ai pas de solution.
Si quelqu’un d’autre a une idée …
Tu n’aurais pas un noyau amd64 sur une installation i386 par hasard?
Peux tu donner la fin de dmesg et de /var/log/syslog après avoir fait le modprobe?
La discussion est un peu vieille, mais je ne l’avais pas vue car le son, ce n’est pas mon domaine…
J’observe une incohérence dans les informations du module :
filename: /lib/modules/3.16.0-4-amd64/kernel/sound/pci/hda/snd-hda-intel.ko
vermagic: 3.2.0-4-amd64 SMP mod_unload modversions
Le module se trouve dans le répertoire du noyau 3.16 mais est prévu pour un noyau 3.2. Il y a un gros problème. Pas étonnant que ça crie dans tous les sens quand on essaie de le charger.
En tout cas je ne vois pas comment ça a pu arriver. Soit c’est une erreur dans le paquet .deb du noyau lui-même (mais j’en doute, ça se serait vu), soit il y a eu mélange entre les répertoires des modules des deux noyaux sur la machine, soit résultat d’une tentative manuelle vouée à l’échec d’utiliser le module du noyau 3.2 avec le noyau 3.16.
J’ai finalement trouvé le problème : les deux noyaux 3.16 et 3.20 (qui correspond à la version unstable) étaient installés en même temps sur mon système, de façon inexplicable compte tenu de la configuration de mon fichier sources.list en testing. Le module alsa installé était celui du noyau 3.16. J’ai complètement réinstallé mon système en version testing. Le problème a bien évidemment disparu.
Donc si ce problème se produit, il faut soit booter sur le noyau 3.16, soit passer en unstable.
Non, le problème ne pouvait pas venir de la présence simultanée des deux noyaux. Plusieurs noyaux peuvent parfaitement être installés et cohabiter sur la même machine, chacun ayant ses propres modules dans son propre répertoire /lib/modules/, un seul étant actif à un moment donné bien sûr. Là, il y avait un module d’un noyau dans le répertoire de l’autre noyau, ce qui ne devrait pas arriver.
P.S. : Tu confonds 3.20 (qui n’existe pas encore, la version 3.18 vient juste d’être publiée) et 3.2.0 qui est la version du noyau dans Wheezy/stable.