Forum : 1 - Le matériel et les pilotes ALSA, FFADO, ...

[ABANDONNÉ] Grésillements avec M-Audio Audiophile 24/96 sous Debian Squeeze, Tango & Seven.

silfeed utilisateur non connecté
Bonjour, bonsoir.


Alors me voilà avec un problème assez gênant qui dure depuis quelques temps.

Sous Debian Squeeze ou bien sous Tango studio, j'ai du grésillement dans mon haut parleur gauche avec une carte son M-Audio Audiophile 2496.

L'ennui c'est que justement j'ai pris cette carte pour des raisons de qualité sonore, tant en écoute qu'en MAO, étant donné le rapport qualité/prix et la relativement bonne réputation qu'a M-Audio en ce domaine.

Néanmoins... j'arrive pas à l'utiliser sans éviter à un moment ce grésillement assez gênant.

J'ai comme carte mère une Gigabyte H57m-usb3.
J'ai désactivé le chipset intégré (Azalia) dans le bios, sans succès...
cat /proc/asound/cards me retourne bien la carte M-Audio.

Ca vient de manière assez bizarre... parfois je ne fais vraiment rien de spécial et ça vient comme par magie.
Pourtant pas des masses d'applications lancées à part pidgin (sans notification sonore) et irssi.
Je constate aussi que lorsque je lance une page web avec du flash, c'est immédiat ; ca grésille.

Lorsque ça arrive, parfois, une petite feinte fait disparaître momentanément le phénomène.
A savoir ; le choix d'un autre serveur son dans "gstreamer-properties".
Ceci au petit bonheur la chance, je n'ai pas trouvé la séquence qui va bien, une fois ça marche directement en changeant vers Alsa puis Pulseaudio, une fois il faut sélectionner un, puis un autre, puis un autre, et parfois rien ne réussit.
-> Alsa, pulseaudio, clic sur test, repasser sur un autre... ou bien carrément redémarrer la machine.

Ensuite, après reboot, parfois tout va bien pendant un temps si je ne fais qu'écouter un fichier audio (en l'occurrence via decibel-audio-player, qui est le lecteur audio que j'utilise généralement) Mais ca reste assez variable, ça peut aller d'une minute à des heures de lecture.
Mais on dirait que dès que la carte est sollicitée par quelque-chose d'autre (mon interprétation, peut être erronée) c'est à nouveau la fête dans mon haut-parleur gauche. :-/

C'est finalement très difficile d'expliquer ce bug, tant il apparaît de manière imprévisible, et peu audible à un volume sonore faible (sauf pour le flash, qui est toujours coupable). Mais lorsque je monte un peu le volume et que le son est en mode "grésillement" ça s'entend assez bien.

Concernant les modules chargés, j'ai constaté que sans le module snd_ac97_codec, ma carte n'est carrément plus présente dans le mixer de Gnome. Et donc je n'ai plus de son du tout sans ce module.

Voici un petit extrait de lsmod et blacklist.conf, mais sans savoir si vraiment c'est causal dans ce cas :
$ cat /etc/modprobe.d/blacklist.conf | grep ac97
#blacklist snd_ac97_codec
blacklist ac97_bus
blacklist snd_ac97_codec



$ lsmod | grep ac97
snd_ac97_codec         99186  1 snd_ice1712
snd_pcm                60503  2 snd_ice1712,snd_ac97_codec
ac97_bus                1086  1 snd_ac97_codec
snd                    46446  13 snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_pcm,snd_i2c,snd_mpu401_uart,snd_rawmidi,snd_seq,snd_timer,snd_seq_device



Si quelqu'un a une idée, un truc à essayer..?

Sinon j'ai pensé aussi que peut être... mon pc est branché à ma TV en HDMI depuis mon ATI 5450...
Peut être un conflit avec l'HDMI?

allany utilisateur non connecté
Bonjour,

Oui, étrange...
Peux-tu poster les résultats de :
cat /proc/asound/cards
aplay -l

en entier ?
Je ne comprends pas bien l'intérêt du blacklist de AC97 puisqu'on retrouve ce dernier dans le lsmod...

A+

silfeed utilisateur non connecté
Bonjour et merci allany.

Alors sous debian forcément comme j'avais blacklisté l'ac97 (le bus) en pensant résoudre le problème, elle n'apparaît plus.

$ cat /proc/asound/cards
 0 [M2496          ]: ICE1712 - M Audio Audiophile 24/96
                      M Audio Audiophile 24/96 at 0xdf00, irq 18


$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: M2496 [M Audio Audiophile 24/96], device 0: ICE1712 multi [ICE1712 multi]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


Par contre sous Tango c'est différent ;

$ cat /proc/asound/cards
 0 [Generic        ]: HDA-Intel - HD-Audio Generic
                      HD-Audio Generic at 0xfbcfc000 irq 17
 1 [M2496          ]: ICE1712 - M Audio Audiophile 24/96
                      M Audio Audiophile 24/96 at 0xdf00, irq 18


$ aplay -l
**** Liste des PLAYBACK périphériques ****
carte  0: Generic [HD-Audio Generic], périphérique 3 : ATI HDMI [ATI HDMI]
  Sous-périphériques: 1/1
  Sous-périphérique: #0: subdevice #0
carte  1: M2496 [M Audio Audiophile 24/96], périphérique 0 : ICE1712 multi [ICE1712 multi]
  Sous-périphériques: 0/1
  Sous-périphérique: #0: subdevice #0


allany utilisateur non connecté
OK...
Je suppose donc que lorsque tu es sous Debian, tu déclares la carte M-audio en hw:0 et, sous Tango, en hw:1 ?
Mais le blème n'est pas là.
Sinon :
- as-tu bien isolé le problème et vérifié que rien ne cloche dans le hardware (HP, câbles, amplification, en inversant droite/gauche, ...) ?
- as-tu le même phénomène avec la carte-son intégrée à la carte-mère ?
- as-tu tenté d'enficher la carte sur d'autres ports PCI ?

Ce qui me parait troublant c'est que le phénomène soit systématique avec web/flash...
Mmmmh, le HDMI, j'ai lu 2-3 trucs mais je ne connais pas assez bien. Il y a un cas, en ce moment, sur le forum, où intervient également du HDMI avec une M-audio Delta 66 mais rien ne prouve que ce soit ça qui soit en cause.
Peut-être un extrait de lspci avec ce qui concerne l'audio ET le HDMI serait utile ?

A+

silfeed utilisateur non connecté
allany écrit :
Je suppose donc que lorsque tu es sous Debian, tu déclares la carte M-audio en hw:0 et, sous Tango, en hw:1 ?
Mais le blème n'est pas là.

C'est bien ca.

Pour l'hardware, j'ai juste constaté que le problème vient de la sortie au niveau de la carte son (M-Audio). Car si j'inverse les cables en entrée au niveau de mon ampli audio (NAD 3020i, analogique donc) le grésillement change de sens.

Pour ce qui est de la carte son intégrée, je n'ai pas essayé. Je vais le faire de ce pas.

Changer de slot PCI non plus, à tester. (Il y en a 2 dispos).

allany écrit :
Ce qui me parait troublant c'est que le phénomène soit systématique avec web/flash...

Pareil... :-/

allany écrit :
Peut-être un extrait de lspci avec ce qui concerne l'audio ET le HDMI serait utile ?


Le voici, en entier ;

ouam@debian64:~$ lspci

[+]
Désolé pour la mise en page du post, je comprend pas bien comment insérer le retour du terminal de manière claire... j'espère que c'est pas trop indigeste.

Merci à toi :-)

silfeed utilisateur non connecté
Bon résultat des courses, il ne me semble pas que ça le fasse avec le chipset intégré. Mais évidement le son est moins pur aussi...

Et changer de slot PCI ne change rien au phénomène.

Par contre j'ai remarqué un truc. (C'est peut être normal, j'avoue ne pas bien savoir à quoi servent certaines options...)

Si dans l'outil d'administration de l'M-Audio (Envy24 control) je laisse l'option Rate State sur "locked", les videos flash en browser sont comme ralentie (comme en 48000 Khz) et il n'y a pas de grésillement.

Par contre, si je décoche l'option, la vitesse de lecture revient à la normale, mais le grésillement revient. O_o

Aussi, je me rend compte que je me suis fourvoyé ;
Alors sous debian forcément comme j'avais blacklisté l'ac97 (le bus) en pensant résoudre le problème, elle n'apparaît plus.

Cette affirmation de ma part est fausse bien entendu puisque j'avais désactivé le chipset dans le BIOS ; rien à voir donc...
En fait, je peux mettre ce que je veux dans le blacklist.conf ca ne change rien au final...

Aussi, il n'y a pas qu'avec les vidéos en flash que ça le fait...
Tout à l'heure simplement en m'authentifiant sur ce site... donc ça devient vraiment difficile à dépister. :o(

allany utilisateur non connecté
Ouaip !

Pour ta question sur la mise en page, quand le log est un peu long, tu le mets entre les balises "code" et tu rajoutes devant le pavé une étoile (*) suivie d'un moins (-). J'ai corrigé sur ton "lspci".

Après, pour le problème qui nous concerne, je suppose que ton "lspci" a été fait avec le chipset interne désactivé ?
Je remarque que, comme pour notre collègue avec la Delta 66, tu as un autre processeur-son dédié au HDMI :
01:00.1 Audio device: ATI Technologies Inc Manhattan HDMI Audio [Mobility Radeon HD 5000 Series]

Peut-être sur la carte vidéo ?
Un petit :
lsmod | grep audio

devrait te donner le nom du module gérant le HDMI. Tu pourrais faire un test en le déchargeant manuellement par :
sudo modprobe -r nom_du_module

Si ça s'avérait efficace, on pourrait peut-être, par la suite, faire en sorte de lui attribuer une priorité inférieure.

Enfin, je n'ai jamais pratiqué le "envy24control" dont je ne connais pas les paramètres...
Quand au blacklistage, je suis en train de rédiger un petit article là-dessus et il semble que les syntaxes aient changé depuis quelques versions Debian/Ubuntu. Je dois encore faire quelques tests... Ca pourrait s'avérer utile si le HDMI était bien en cause.

A+

silfeed utilisateur non connecté
Re,

Merci pour tes conseils.

Malheureusement j'avais déja blacklisté ce module.

Voilà en fait ce que j'ai mis par moi même dans le blacklist en cherchant à coup de lsmod ;

[+]


Donc en fait ben lsmod | grep audio ne me retourne rien.
Par contre lsmod | grep snd ne m'affiche plus snd_hda_codec_atihdmi comme avant (qui doit être celui dont on parle) donc... ben c'est pas ça :-/ Je me souviens que ça m'avait fait sauter de joie en croyant que... et finalement bah.... ça changeait rien.

Pour le lspci, je ne sais plus trop si j'avais laissé le chipset ou pas dans le BIOS. Veux tu que j'en reposte un?

allany utilisateur non connecté
OK,
Pour le blacklist, voici un extrait du tuto que je suis en train de rédiger :
il semble que, sur certaines distributions récentes,
le fichier général "blacklist" ait été remplacé par plusieurs fichiers
nom_module.conf, sous /etc/modprobe.d, lesquels contiennent la ligne :
blacklist nom_module

à vérifier, donc, dans la distribution que tu utilises, si tu n'as pas déjà des fichiers .conf sous /etc/modprobe.d et, éventuellement, en créer un spécifique pour ce module HDMI, avec le même formalisme.
Le résultat des courses m'intéresse, bien sûr, doublement puisque ça confirmerait aussi la syntaxe exacte pour blacklister.
Vérifie l'efficacité de chacune des manip's, après reboot, par lsmod.

MAIS, AVANT de modifier blacklist, essaie quand même le déchargement manuel du module, par :
sudo modprobe -r snd_hda_codec_atihdmi 
s'il s'agit bien de ce dernier

et en vérifiant avec lsmod, sans rebooter, cette fois-ci, qu'il a bien disparu.

Tout ça pour isoler cette question sur le HDMI, sachant qu'il est possible que ce ne soit pas la bonne piste... Ce sera fait !

A+

silfeed utilisateur non connecté
allany écrit :
essaie quand même le déchargement manuel du module


En fait je l'avais blacklisté déjà, donc il n'apparaissait pas dans le lsmod.

J'ai fait comme tu m'as dit.
Voilà en gros ce que j'ai fait en toute logique en m'inspirant aussi de cette page Debian :

[+]

Bref je suis pas convaincu qu'il ne suffisait pas de compléter le blacklist.conf.
Car si je ne m'abuse, le nom du fichier importe peu, c'est le .conf à la fin qui est nécessaire je crois. Peut être ont-ils proposés chez Debian de segmenter par nom_module.conf pour plus de clarté? Mais je peux (encore) me tromper. :-D

Quoi qu'il en soit, au reboot c'est toujours pareil, le lsmod reste inchangé. Et mon bug aussi... :_(

Pour que tu en aies le coeur net, voilà mon lsmod complêt après reboot :

[+]

Ainsi que le contenu du rep modprobe.d :
(à propos, est ce normal la présence de ce linux-sound-base_noOSS.conf?)

[+]

Et pour finir, le contenu de ce linux-sound-base_noOSS.conf car je ne me souviens plus si il y était dès l'install de Squeeze... ;

[+]

allany utilisateur non connecté
Récapitulons :
- pas de problème avec le chipset intégré,
- le problème persiste en n'ayant que la M-audio comme unique carte-son,
- ça ne semble pas provenir d'un conflit avec HDMI,
- ça n'affecte que le canal gauche de la M-audio,
- peu importe le slot utilisé sur la carte-mère,
donc j'aurais tendance à dire que le souci serait lié à l'environnement très proche de la carte elle-même (driver Alsa/envy24control/hardware carte).
Ce modèle de carte semble très répandu parmi les afficionados du site et je ne me souviens pas d'avoir vu passer de problème lié au driver...

Dans l'onglet "hardware settings" de Envy24, que déclares-tu ?
Dans la doc officielle, il apparait que certains paramètres peuvent affecter la bonne marche de l'ensemble... sous Win ou OS/X.

Par acquis de conscience, peux-tu poster un :
lspci -v

de la config' telle qu'elle est actuellement sous Tango, pour voir la gestion des priorités (latency_timer) ?

Si tu bootes sur Tango en live-DVD, que disent :
aplay -l
cat /proc/asound/cards
lspci -v

et le phénomène se reproduit-il à l'identique ?

A+

silfeed utilisateur non connecté
Bon c'est un truc de fou !

Alors j'ai donc booté Tango live.

En fait j'ai mis aussi sur ma clé usb* un mode persistant pour Tango, en pensant que je devrais rajouter (comme sur toutes distrib' dérivée de Debian) slave.format S32_LE et slave.channels 10 comme mentionné sur ce blog (étant un des blogs du Planet Ubuntu Fr quand même) pour avoir du son avec ma carte.

Mais là, je me suis rendu compte qu'en bootant en mode live persistant, c'est inutile. 0_o

Donc je me dis, je vais rebooter en mode live non persistant pour voir pourquoi j'avais pas de son.

Et là... j'ai ma carte M-Audio qui a changé de plaçe dans /proc/asound/cards ! (gasp)


En résumé :

En mode live persistant, j'ai du son, (sans devoir faire la manip du blog + reboot), et pour cause la carte M-Audio est en position 0.
Mais toujours le bug, et sans même lancer autrechose qu'exaille, directement!

En mode live non persistant, j'ai pas de son du tout.
Donc, la carte Intel (intégrée) passe en position 0 et l'autre en 1, mais elle n'est toujours pas active dans mon BIOS !! Donc pas de son.

Vraiment bizarre...

Alors en ce qui concerne envy24 control, voici ce que j'ai :

Capture

Je joins aussi ce que tu m'as demandé ;

Depuis Tango, installé sur mon disque dur ;

[+]

Depuis Tango mode live persistant ;

[+]

[+]

[+]

Je commence à me poser des questions quand aux intentions cachées de mon matériel... :-°

Merci beaucoup pour ta patience et ton aide.

(*) Au cas où tu te demandais ce que j'ai utilisé à cet effet, simplement cette appli indispensable ; "multisystem" :o)

PS : MMhh je vois que quand on utilise "code" il vire ce qui est entre les balises...
Pas pratique... En gros il était écrit acces denied après Capabilities.





@+

allany utilisateur non connecté
Bon,

Je viens de perdre 2 saisies pour cause de déconnexions intempestives.
Je la fais donc brève.
L'IRQ 18, sur laquelle est la carte M-audio, est également utilisée par deux contrôleurs USB (Intel et NEC).
Il faudrait que tu vérifies, par Synaptic, que rtirq soit bien installé. Sinon, le faire.
Après, il serait intéressant de voir le contenu de :
/etc/default/rtirq (init-irq, rtirq-init, ou approchant...)

Pour les latency_timer, on laisse béton, pour l'instant.

Sur les réglages d'envy24, je vois que tu es en mode "professional". Sur ma carte Echo, je ne peux fonctionner qu'en mode "consumer" et, dans la doc M-audio, ils semblent dire que l'usage "professional" nécessite tout un environnement très particulier, bien que je n'aie pas tout compris...

Bon, j'espère que le serveur va bien poster ce truc, cette fois-ci...

A+

silfeed utilisateur non connecté
:-/ Désolé pour tes décos...

Mmhh... tout ce que je trouve s'approchant d'rtirq sous Squeeze c'est ;

[+]

Sous Tango ;

[+]

Pour la sortie s/pdif j'ai mis maintenant en mode "consumer" sous Squeeze, mais sous Tango c'était déjà en ce mode.
Que ca soit l'un ou l'autre, en fait, ça n'a pas l'air d'avoir une quelconque incidence sur quoi que ce soit.

@+

allany utilisateur non connecté
Salut !

Curieux car je viens de vérifier, sur ma TangoStudio, et j'ai bien, sous /etc/default, ce fichier rtirq (c'est le nom exact) dont le contenu attribue les priorités en fonction de l'audio.
J'étais persuadé qu'il était installé par défaut dans Tango mais comme ça fait un moment, je ne me souviens pas précisément.
Comme tu n'as rien qui y ressemble, il faudrait que tu voies, avec Synaptic, s'il te propose bien rtirq à l'installation.

Puisqu'on est dans les priorités, qu'as-tu comme valeur de rtprio dans /etc/security/limits.d/audio.conf et que mets-tu, toujours en priorité, dans Jack ? Si ce n'est pas le cas, tu soustrais 10 à rtprio pour renseigner la priorité de Jack.

C'est un peu long, désolé, mais autant procéder par élimination en souhaitant qu'au final ce ne soit pas, tout bêtement, l'électronique de la carte qui bugge... D'ailleurs, si tu as un quelconque moyen de la tester dans un autre environnement (machine, OS,...) ça lèverait cette ambiguïté à laquelle je songe depuis un moment.

Mais, de toutes façons, ces histoires d'IRQ et de priorités peuvent, lors d'une interruption système (affichage, frappe clavier, mouvement souris, etc...), ficher le bazar sur la machine. Et que ta carte-son partage son IRQ avec DEUX contrôleurs USB ne me parait pas très raisonnable...

Si tu modifies tes IRQ, renvoie les mêmes infos que précédemment.

A+

silfeed utilisateur non connecté
allany écrit :
D'ailleurs, si tu as un quelconque moyen de la tester dans un autre environnement (machine, OS,...) ça lèverait cette ambiguïté à laquelle je songe depuis un moment.


Bon, et bien ça le fait sous Seven aussi.

Faut il chercher plus loin? :_(

Voilà pour l'autre OS.
Pour le test sur une autre machine faudrait que j'aille chez un ami (chez qui j'ai aussi installé Tango :-)), j'ai qu'une machine à disposition chez moi.

Le truc bizarre quand même, c'est que sous Seven c'est exactement pareil avec flash ; tout à l'air d'aller (j'ai testé sous foobar2000) tant que je ne lance pas un truc genre youtube...

Merci pour ta patience.

Si ça peut t'aider je veux bien refaire une install de Tango pour voir au sujet de rtirq. Mais je viens de rentrer, donc pas ce soir, demain.

@+

allany utilisateur non connecté
Bon, ben désolé pour toi !

Un problème hardware, donc, on dirait bien.
Ce qui m'avait mis la puce à l'oreille, dès le début, c'est que tu n'avais ce bruit que sur le canal gauche.
Côté Linux, Alsa, Jack, etc, on est maintenant hors de doute.
Pour être sûr de ton coup, il faudrait effectivement monter la carte chez un pote pour savoir, au final, s'il s'agit d'un dysfonctionnement de la carte ou du bus PCI de ta machine voire, éventuellement, des IRQ partagées.

J'ignore comment Seven gère ses IRQ aussi tu peux tenter cette install' de rtirq sous ta TangoStudio. Il reste une chance très, très infime au cas où ce serait géré de la même façon sous les deux systèmes et que le problème viendrait de cette attribution croisée des IRQ...
Je ne pense pas qu'il soit nécessaire de tout réinstaller, il suffit de passer par Synaptic pour implanter rtirq.
Ce qui m'inquiète un peu, c'est que je suis presque persuadé que rtirq était installé d'origine sur ma version de TS. Dans ce cas (hypothétique) pourquoi pas sur ta machine ? Incompatibilité avec le bus ? Guette, si tu l'installes, les messages d'erreur et autres logs.

De toute manière autant tout tester avant de poubeller du matos, non ?

A+

silfeed utilisateur non connecté
allany écrit :
De toute manière autant tout tester avant de poubeller du matos, non ?


Bien sûr, d'autant qu'à un mois près, elle n'est plus sous garantie...grrr... (J'aurais dû venir poster ici bien plus tôt, mais bon j'ai préféré chercher de mon côté comme un petit individualiste que je suis parfois :-D).

Pour ce qui est d'rtirq, ne figurant pas dans les paquets (tel quel ; que ce soit via synaptic, apt-get, ou aptitude c'est pareil) j'ai donc installé rtirq-init via apt-get, puisque c'est ce qu'utilise synaptic en fond.
Ceci surtout pour pouvoir copier/coller plus façilement le retour du terminal.


[+]

Pour le test chez le pote, rendez-vous en cours de préparation, ca ne saurait tarder des masses :-)

Bizarre qu'il n'y ait pas d'rtirq (tel quel) chez moi, comme chez toi !
( °°)

En tout cas tu as une patience incroyable, merci encore. :-)


@+ tard

allany utilisateur non connecté
silfeed écrit :
d'autant qu'à un mois près, elle n'est plus sous garantie...grrr... (J'aurais dû venir poster ici bien plus tôt, mais bon j'ai préféré chercher de mon côté comme un petit individualiste que je suis parfois

Sale coup pour la garantie, si c'est bien le blème...
Quand à "l'individualisme", ça nous aura au moins permis de pas rabâcher tout le B-A-ba, j'apprécie, de mon côté, de bosser à niveau d'expérience égal.
Excuse-moi pour rtirq, il est fort possible (sinon certain vu les logs) qu'il s'agissait de rtirq-init. Je poste à partir d'une autre machine que celle qui ne fait que de la mao/Linux et je ne vérifie pas toujours... Un étage m'en sépare wink.
Pour Synaptic/apt-get, c'est pareil, pas de souci et, t'as raison, comme ça on a le log.

silfeed écrit :
En tout cas tu as une patience incroyable, merci encore

1- ton problème m'intriguait,
2- avec ma carte, j'ai galéré une bonne semaine, autant tirer profit de l'expérience,
3- j'aurais franchement préféré qu'on trouve une réponse plus agréable,
4- tu m'as filé la réponse, pour blacklister wink.

Envoie quand même un lspci -v avec la nouvelle install de rtirq-init, on ne sait jamais.

A+

silfeed utilisateur non connecté
allany écrit :
ça nous aura au moins permis de pas rabâcher tout le B-A-ba, j'apprécie, de mon côté, de bosser à niveau d'expérience égal.


Merci, c'est flatteur :-D

allany écrit :

Envoie quand même un lspci -v avec la nouvelle install de rtirq-init, on ne sait jamais.


Le voici, mais ayant chipoté un peu au Bios j'espère avoir remis tout comme c'était depuis le dernier post (au niveau des IRQ) ;

[+]

A priori je ne vois pas de différence... Reste donc à faire le test sur une autre architecture. (Bientôt)

@+

allany utilisateur non connecté
Bon, résultat des courses : rien côté rtirq !
Ca revient au même, avec toujours les 2 contrôleurs USB sur la même IRQ que la M-audio (18).
Ce qui est intéressant, par contre, c'est que le module snd-hda-intel est toujours bien là pour gérer le HDMI...
Fais un test en le déchargeant par :
sudo modprobe -r snd-hda-intel

Tu peux à tout moment le recharger, si ça fiche le bazar, par:
sudo modprobe snd-hda-intel

ou en redémarrant la machine, le modprobe -r étant volatile.

A+

Page : 1/2