Comment supprimer un module chargé ?

Support Debian
#1

Salut,
Je viens d’installer zoneminder, mais je viens de me rendre compte que ma “webcam” ne fonctionne plus…
Cette caméra fonctionnait il n’y a pas si longtemps, mais je ne m’en sert jamais, et… je ne sais donc pas pourquoi elle ne fonctionne plus…

Quelques infos :

lsusb | grep Camera Bus 008 Device 004: ID 0c45:613c Microdia PC Camera (SN9C120) dmesg [32995.292028] usb 8-1: new full speed USB device using uhci_hcd and address 4 [32995.510039] usb 8-1: New USB device found, idVendor=0c45, idProduct=613c [32995.510042] usb 8-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [32995.510045] usb 8-1: Product: USB camera [32995.513100] gspca: probing 0c45:613c [32995.518037] sonixj: Sonix chip id: 12 [32995.520095] input: sonixj as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/input/input8 [32995.520191] gspca: video0 created
Je soupçonne un module de mettre le bazar.

camorama (camorama:2941): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated libv4l2: error dequeuing buf: Erreur d'entrée/sortie

Suite à cette commande je suppose que c’est lib4l2 qui bloque…

Les modules qui devraient être en rapport avec la caméra :

lsmod | grep video + lsmod | grep gspca

videodev               65576  1 gspca_main
v4l1_compat            11997  1 videodev
v4l2_compat_ioctl32     9262  1 videodev
i2c_core               22963  4 nvidia,videodev,max6650,i2c_i801
gspca_sonixj           25223  0 
gspca_main             21876  1 gspca_sonixj
usbcore               143377  8 ipheth,gspca_sonixj,gspca_main,usbhid,usb_storage,uhci_hcd,ehci_hcd

Donc, fort des ces infos, je décide d’essayer de désactiver certains modules à commencer par v4l2_compat_ioctl32

modprobe -r v4l2_compat_ioctl32 FATAL: Module v4l2_compat_ioctl32 is in use.

Il ne veut rien savoir et je le comprend… (même avec l’option --force - j’ai lu le man quand même)
Je suis nul dans ces histoires de modules, je ne sais pas comment procéder…

#2

Essaye peut être rmmod ?

Sinon, tu le blacklistes (en l’ajoutant dans /etc/modprobe.d/blacklist.conf) et tu rebootes.

#3

A tout hasard:

rmmod :question:
Arrr, Grilled :005

#4

Re,

rmmod v4l2_compat_ioctl32 ERROR: Module v4l2_compat_ioctl32 is in use by videodev

J’ai eu un doute, si ça avait fonctionné, la honte… :ugeek:
Oui, le “black-listage”, évidemment. Je n’y avais pas pensé…
Je n’avais pas envie de redémarrer, mais j’ai l’impression que je n’ai pas le choix…

Merci.

Edit… la commande rmmod précise quand même : “v4l2_compat_ioctl32 is in use by videodev”

rmmod videodev ERROR: Module videodev is in use by gspca_main rmmod gspca_main ERROR: Module gspca_main is in use by gspca_sonixj rmmod gspca_sonixj rmmod gspca_main rmmod videodev rmmod v4l2_compat_ioctl32
Cool… Mais ma caméra ne fonctionne pas plus… Quand je la connecte rebelote avec les modules.
Je blacklist et redémarre… A +

#5

La commande “modprobe -r Nom_du_Module” n’est pas faite pour supprimer un module ?
Sauf si rmmod = modprobe -r :mrgreen:

#6

Bon,
Il va surement falloir que j’édite le titre de mon fil…
Je n’ai pas résolu mon problème

J’ai bien ajouté ceci à /etc/modprobe.d/blacklist.conf

blacklist v4l2_compat_ioctl32

Mais le module est chargé.

lsmod | grep v4l2_compat_ioctl32 v4l2_compat_ioctl32 9262 1 videodev

Et je ne suis même pas sur que ce soit ce module qui est en cause… :017

@Berillon : Si. Mais elle ne donne pas la “dépendance” à d’autres modules. Pour ça la sortie de rmmod est plus complète (enfin c’est ce que j’ai cru comprendre…

#7

man modprobe.conf

“blacklist” sert seulement à empêcher un module d’être chargé sous le nom d’un de ses alias internes, mais cela ne l’empêche d’être chargé sous son nom canonique.

#8

pff c’est tordu :snooty:
mais bon à savoir ! :think:

#9

[quote=“PascalHambourg”]man modprobe.conf

“blacklist” sert seulement à empêcher un module d’être chargé sous le nom d’un de ses alias internes, mais cela ne l’empêche d’être chargé sous son nom canonique.[/quote]

Merci.
J’ai suivi…

Donc:

[quote]modprobe -l | grep v4l2
kernel/drivers/media/video/v4l2-compat-ioctl32.ko
kernel/drivers/media/video/v4l2-int-device.ko
kernel/drivers/media/video/v4l2-common.ko
Ou
modinfo v4l2_compat_ioctl32
filename: /lib/modules/2.6.36-rc5-amd64/kernel/drivers/media/video/v4l2-compat-ioctl32.ko
license: GPL
depends:
vermagic: 2.6.36-rc5-amd64 SMP mod_unload modversions [/quote]

Il manquait le .ko
J’espère que ça va suffire…

En tout cas pour le titre de ce fil c’est résolu (je redémarre quand même avant)

#10

non… je ne suis pas sur d’avoir suivi…
Je me retape le man (il n’est pas très long…)

#11

Qu’est-ce qui est tordu ? Le fonctionnement de l’option blacklist ?
Le but est essentiellement d’empêcher un module d’être chargé par hotplug ou udev, qui utilisent les alias construits à partir de l’énumération des périphériques détectés pour charger le module pilote correspondant.

On notera au passage que le fichier /etc/modprobe.d/blacklist fait partie du paquetage udev.

@lol : on n’a pas besoin d’écrire le .ko. Ne pas confondre le nom du module (sans chemin ni .ko) et le nom du fichier (avec le chemin et le .ko).

#12

Oui,
C’est bien ce qui me chagrine…

J’ai bien le nom complet du module dans le fichier blacklist, et le module est quand même chargé.

cat /etc/modprobe.d/blacklist.conf | grep v4l2 blacklist v4l2-compat-ioctl32

C’est que j’ai raté un truc…

#13

Non, c’est normal.
Modprobe charge le module v4l2-compat-ioctl32 parce que c’est une dépendance du module videodev, comme le montre modinfo videodev. L’option blacklist ne peut rien contre ça, elle n’est pas faite pour cela comme je l’ai expliqué. C’était pas clair ?

#14

[quote=“PascalHambourg”]Non, c’est normal.
Modprobe charge le module v4l2-compat-ioctl32 parce que c’est une dépendance du module videodev, comme le montre modinfo videodev. L’option blacklist ne peut rien contre ça, elle n’est pas faite pour cela comme je l’ai expliqué. C’était pas clair ?[/quote]

Franchement ? :wink:
Maintenant oui ça l’est. Je n’avais pas bien capté l’histoire des dépendances (J’aurais du comprendre dés le début, puisque j’ai réussi à désactiver les modules un par un en remontant les dépendances)…

Ce qui est con… C’est qu’un modinfo v4l2-compat-ioctl32 ne donne pas le module dont il dépend…
modinfo donne les dépendances ascendantes, pas descendantes…

Merci.

#15

Je suis une bille…
Les dépendances des modules sont listées avec lsmod…

gspca_sonixj 25223 0 gspca_main 21876 1 gspca_sonixj videodev 65576 1 gspca_main v4l1_compat 11997 1 videodev v4l2_compat_ioctl32 9262 1 videodev

Donc inutile de blacklister v4l2_compat_ioctl32 et cie… la caméra ne fonctionnera pas sans gspca…

#16

Je passe en résolu,
Ce problème de module est compris, assimilé et réglé.

Je n’ai pas résolu mon souci de webcam, mais c’est un autre problème…

Merci à vous.

#17

Tu es certain que c’est un problème de module ?
Ce ne serait pas tout simplement zoneminder qui monopolise la cam ?

#18

[quote=“piratebab”]Tu es certain que c’est un problème de module ?
Ce ne serait pas tout simplement zoneminder qui monopolise la cam ?[/quote]

Salut,
C’est sympa, mais la caméra ne fonctionnait pas avant l’installation de zoneminder.
Je m’en moquait un peu car je ne l’utilisais pas, maintenant, c’est différent… :wink:

Au fait zoneminder… apt-get install zoneminder… C’est plus simple que de compiler les sources… :mrgreen:

#19

OK, j’avais compris le contraire.
Ouvre un fil pour ta camera.

#20

Re,

[quote=“piratebab”]OK, j’avais compris le contraire.
Ouvre un fil pour ta camera.[/quote]

Oui, si je n’arrive à rien je le fais.
J’ai le flemme ce soir, pas les idées très claires… Et puis je viens de me cogner des dizaines de pages de forums sur ce problème de caméra… Et pas toutes digestes… :005

Parfois la lumière vient pendant le sommeil…

Je viens de voir ta réponse sur l’autre fil…
Merci.