Impossible de supprimer un module

Bonsoir,

Ayant acheté une clé wifi qui fonctionne enfin sur 64bits dans le but de remplacer la carte wifi intégré à mon laptop, j’ai donc voulu supprimer le module “r8192_pci”.

Le hic, c’est que ca m’est impossible de le faire, j’ai un beau message qui m’est totalement incompréhensible :

[code]root@Sidex:/home/berillions/Bureau# rmmod r8192_pci
Processus arrêté

Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673787] Oops: 0002 [#1] SMP
root@Sidex:/home/berillions/Bureau#
Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673790] last sysfs file: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ieee80211/phy1/rfkill0/uevent

Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673881] Stack:

Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673892] Call Trace:

Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673957] Code: 89 f0 48 89 d0 75 13 48 be 00 00 00 00 00 88 ff ff 48 8d 34 37 4c 89 c7 eb 0e 48 bf 00 00 00 00 00 88 ff ff 49 8d 3c 39 48 89 c1 a4 59 c3 41 55 49 89 d5 41 54 45 89 c4 55 48 89 f5 53 89 cb

Message from syslogd@Sidex at Nov 3 18:40:25 …
kernel:[ 5205.673985] CR2: 0000000000000020
[/code]

Soit celui-ci :

root@Sidex:/home/berillions/Bureau# rmmod r8192_pci ERROR: Removing 'r8192_pci': Device or resource busy

Je précise également que j’ai désactivé mon chipset dans le BIOS du PC Portable. Et que nm-applet me trouve toujours ce fichu réseau sans fil REALTEK 8192E…

Bref.

Tu peux tenter de blacklister le module et ensuite du redémarre le système.

Pour blacklister un module, ajoute le au fichier /etc/modprobe.d/blacklist

SI c’est le module r8192se_pci sur 64 bits que tu cherches, j’ai mis du temps mais ai trouvé un module parfaitement fonctionnel…

Mon chipset Wifi est le Realtek 8192e.
Les drivers sont en staging dans le kernel et les firmwares sont disponibles via le paquet “firmware realtek”.

En 32 bits, le chipset fonctionne très bien.
En 64 bits, j’arrive à me connecter 1 fois sur 10 pour peu de temps. Connexion très instable.

Je ne suis pas le seul à être touché par ce chipset maudit en 64bits :smiley:

EDIT: fran.b, vu que tu es un grand manitou de Debian, j’ai deux lignes d’erreurs à propos de ma clé wifi au boot, après le chargement de /dev.
Dans quel fichier de /var/log je peux trouver ça vu que ca assez vite… :violence-captureflagred:

EDIT2: Chose marrante, j’arrive à me connecter à mon réseau via cette clé wifi en 2.6.32 et dès que je boot sur le noyau d’experimental (2.6.36) = impossible…
Le 64bits ne veut vraiment pas de moi :119

EDIT3 : Ces problèmes pourraient venir du routeur ? :017

Pour l’EDIT1, j’ai trouvé ce fameux message d’erreur :

[ 8.079319] phy0 -> rt2500usb_init_eeprom: Error - Invalid RT chipset detected. [ 8.079414] phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device. [ 8.079551] usbcore: registered new interface driver rt2500usb

Bon, j’ai tout de même internet même si le débit et moins bon qu’en 32bits…

Venir du routeur non, que donne /var/log/syslog avec le noyau experimental?

J’ai regardé sans le syslog comme demandé.
A première vu, lorsque je tente de me connecter à mon réseau et que cela ne fonctionne pas (alors que j’ai les 2 boules vertes), c’est que la requête DHCP a échoué…

Nov  4 09:41:33 Sidex dhclient: DHCPREQUEST on wlan1 to 255.255.255.255 port 67
Nov  4 09:41:38 Sidex dhclient: DHCPREQUEST on wlan1 to 255.255.255.255 port 67
Nov  4 09:41:49 Sidex dhclient: DHCPDISCOVER on wlan1 to 255.255.255.255 port 67 interval 3
Nov  4 09:41:52 Sidex dhclient: DHCPDISCOVER on wlan1 to 255.255.255.255 port 67 interval 8
Nov  4 09:42:00 Sidex dhclient: DHCPDISCOVER on wlan1 to 255.255.255.255 port 67 interval 9
Nov  4 09:42:09 Sidex dhclient: DHCPDISCOVER on wlan1 to 255.255.255.255 port 67 interval 14
Nov  4 09:42:14 Sidex NetworkManager[1784]: <warn> (wlan1): DHCPv4 request timed out.
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> (wlan1): canceled DHCP transaction, DHCP client pid 2192
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 4 of 5 (IP4 Configure Timeout) scheduled...
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 4 of 5 (IP4 Configure Timeout) started...
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 5 of 5 (IP Configure Commit) scheduled...
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 4 of 5 (IP4 Configure Timeout) complete.
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 5 of 5 (IP Configure Commit) started...
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Activation (wlan1) Stage 5 of 5 (IP Configure Commit) failed (no IP configuration found)
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> (wlan1): device state change: 7 -> 9 (reason 5)
Nov  4 09:42:15 Sidex NetworkManager[1784]: <warn> Activation (wlan1) failed for access point (belkin54g)
Nov  4 09:42:15 Sidex NetworkManager[1784]: <info> Marking connection 'Auto belkin54g' invalid.
Nov  4 09:42:15 Sidex NetworkManager[1784]: <warn> Activation (wlan1) failed.

Et ceci n’arrive quand 64bits. Sous 32bits, je n’ai jamais eu un problème de requête DHCP, la connexion s’est toujours faite du 1er coup.
Pour ca que je vais repasser en 32bits, marre de batailler avec le 64bits. De toute manière, le 32bits a encore de beaux jours devant lui avant de disparaitre. D’ici là, j’aurais un autre laptop.

As tu essayé une configuration à la main pas à pas?

Je l’ai essayé juste après l’installation de Debian. J’ai modifié le fichier /etc/network/interfaces pour y mettre ma configuration wifi. Lors du 1er et 2nd démarrage de test, le wifi a fonctionné d’ou l’installation par la suite de networkmanager.

Hier soir, je démarre la machine, j’ai du wifi donc tout marche très bien. Et vers 22h30-23h après être allé sur Seven, j’ai reboot sur Debian, plus de Wifi.

Ce matin, je démarre, j’ai du wifi. J’en profite pour installer les drivers nvidia puis je reboot et plus de wifi…

Un petit gars du forum anglais d’archlinux datant du 23/09/2010:

[code]My TP-Link TL-WN321G works great with a 2.6.33 kernel. However, it does not work with a 2.6.35 kernel (rt73usb driver). It’s detected, it can scan for wifi networks, but it won’t connect.

Searching the forums for “rt73usb” indicates that anything using that driver should currently be avoided.[/code]

Même symptôme que moi avec un noyau récent. Je sais toujours aussi bien choisir une clé wifi fonctionnelle moi :005

Quelques petites news. J’ai fait un test cette fois-ci avec wicd à la place de networkmanager.

Chipset Realtek 8192e :
Message d’erreur comme quoi le mot de passe est erroné (alors qu’il est correcte. En driver pour wpasupplicant, j’ai laissé sur wext)

Clé Wifi WN321G :
Il passe la validation du mot de passe mais plante sur l’obtention de l’adresse IP. Vraiment bizarre cette histoire…

Le 64bits ne veut vraiment pas de moi…
J’ai l’impression que ca vient du routeur mais tout fonctionne sur Seven64 donc bon…

Hum, bon

  1. il faudrait que tu fasses un «lspci -v» lorque ça marche et lorsque ça ne marche pas pour voir si deux modules ne se disputent pas la gestion de ton Wifi.

  2. As tu essayé en configurant ta carte via iwconfig et wpa_supplicant directement?

[quote=“fran.b”]Hum, bon

  1. il faudrait que tu fasses un «lspci -v» lorque ça marche et lorsque ça ne marche pas pour voir si deux modules ne se disputent pas la gestion de ton Wifi.[/quote]
    Faut savoir que lorsque je teste mon chipset interne, le module pour ma clé Wifi n’est pas activé vu que celle-ci n’est pas branché.
    Puis quand je teste la clé wifi, je blacklist le module du chipset intégré.

Lorsque je tape iwconfig, ma carte et ma clé sont reconnues. Il y a une autre manière de configuré cela?