web-dev-qa-db-fra.com

Qu'est-ce qui provoque la déconnexion de mon périphérique Bluetooth Intel 7260 lorsque je le débloque avec rfkill?

SOLUTION: Le problème semble être que le module Bluetooth ne fonctionne pas bien avec xHCI sous Linux. Il existe un paramètre du BIOS intitulé "XHCI PRE-BOOT MODE", qui doit être réglé sur "Disabled". Si ce n'est pas le cas, Linux traitera le module Bluetooth comme s'il était connecté à un bus xHCI au lieu d'un bus EHCI, ce qui provoquerait des erreurs de communication. TOUTEFOIS, CETTE FIXE DESACTIVERA L'USB 3.0 SUR VOTRE SYSTEME . Je n'ai pas de meilleure solution pour le moment, mais au moins ça marche.

J'ai un nouvel ordinateur portable ASUS UX301LA et j'utilise Ubuntu Gnome 13.10 (Saucy). Le noyau semble connaître le périphérique Bluetooth de l'ordinateur portable au démarrage, mais il disparaît chaque fois que j'utilise rfkill pour débloquer le Bluetooth. Par exemple:

$ Sudo rfkill block bluetooth
$ dmesg | tail -5
[ 2024.876537] usb 2-4: new full-speed USB device number 8 using xhci_hcd
[ 2024.894043] usb 2-4: New USB device found, idVendor=8087, idProduct=07dc
[ 2024.894053] usb 2-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2024.908190] Bluetooth: hci0: read Intel version: 370710018002030d00
[ 2024.908271] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[ 2025.057051] Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated

$ Sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: asus-wlan: Wireless LAN
    Soft blocked: no
    Hard blocked: no
2: asus-bluetooth: Bluetooth
    Soft blocked: yes
    Hard blocked: no
3: hci0: Bluetooth
    Soft blocked: yes
    Hard blocked: no

$ Sudo hciconfig -a
hci0:   Type: BR/EDR  Bus: USB
    BD Address: XX:XX:XX:XX:XX:XX  ACL MTU: 1021:5  SCO MTU: 96:5
    DOWN 
    RX bytes:568 acl:0 sco:0 events:29 errors:0
    TX bytes:390 acl:0 sco:0 commands:29 errors:0
    Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH HOLD SNIFF 
    Link mode: SLAVE ACCEPT 

$ Sudo rfkill unblock bluetooth
$ dmesg | tail -1
[ 2391.749122] usb 2-4: USB disconnect, device number 8

$ Sudo rfkill list
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: asus-wlan: Wireless LAN
    Soft blocked: no
    Hard blocked: no
2: asus-bluetooth: Bluetooth
    Soft blocked: no
    Hard blocked: no

$ Sudo hciconfig -a
[no output]

EDIT: le périphérique Bluetooth apparaît sous la forme d'un périphérique USB sans fil Intel 7260, ID 8087: 07dc. La seule information que je trouve susceptible d'être pertinente est un bogue pour lequel un correctif a été publié, mentionné sur le tableau de bord ici: Support pour Intel 7260 bluetooth [8087: 07dc]

EDIT: J'ai mis à jour le firmware avec la nouvelle version 22.1.7.0 du site Web d'Intel (Saucy est livré avec 22.0.7.0) et le même problème se produit.

EDIT: des recherches plus approfondies dans les journaux indiquent que le périphérique USB Bluetooth est complètement déconnecté lorsque j'exécute la commande unblock:

$ lsusb -d 8087:07dc
Bus 001 Device 007: ID 8087:07dc Intel Corp. 
$ rfkill unblock bluetooth
$ lsusb -d 8087:07dc
[no output]
$ dmesg | tail -1
[  438.284647] usb 1-4: USB disconnect, device number 7

EDIT: La mise à jour du pilote iwlwifi vers un backport (plus récent) à partir du noyau 3.13 n'aide pas. La version actuelle du pilote:

$ modinfo iwlwifi
filename:       /lib/modules/3.11.0-15-generic/updates/drivers/net/wireless/iwlwifi/iwlwifi.ko
version:        backported from Linux (v3.13-rc8-0-g7e22e91) using backports v3.13-rc8-1-0-gae71bd3
license:        GPL
author:         Copyright(c) 2003-2013 Intel Corporation <[email protected]>
version:        in-tree:d
description:    Intel(R) Wireless WiFi driver for Linux
firmware:       iwlwifi-100-5.ucode
firmware:       iwlwifi-1000-5.ucode
firmware:       iwlwifi-135-6.ucode
firmware:       iwlwifi-105-6.ucode
firmware:       iwlwifi-2030-6.ucode
firmware:       iwlwifi-2000-6.ucode
firmware:       iwlwifi-5150-2.ucode
firmware:       iwlwifi-5000-5.ucode
firmware:       iwlwifi-6000g2b-6.ucode
firmware:       iwlwifi-6000g2a-5.ucode
firmware:       iwlwifi-6050-5.ucode
firmware:       iwlwifi-6000-4.ucode
firmware:       iwlwifi-3160-7.ucode
firmware:       iwlwifi-7260-7.ucode
srcversion:     F6C7F0E202757B474065F3B
alias:          pci:v00008086d0000095Asv*sd00005490bc*sc*i*
[... trimmed several "alias" lines ...]
alias:          pci:v00008086d00004232sv*sd00001201bc*sc*i*
depends:        compat,cfg80211
vermagic:       3.11.0-15-generic SMP mod_unload modversions 
parm:           debug:debug output mask (uint)
parm:           swcrypto:using crypto in software (default 0 [hardware]) (int)
parm:           11n_disable:disable 11n functionality, bitmap: 1: full, 2: agg TX, 4: agg RX (uint)
parm:           amsdu_size_8K:enable 8K amsdu size (default 0) (int)
parm:           fw_restart:restart firmware in case of error (default true) (bool)
parm:           antenna_coupling:specify antenna coupling in dB (defualt: 0 dB) (int)
parm:           wd_disable:Disable stuck queue watchdog timer 0=system default, 1=disable, 2=enable (default: 0) (int)
parm:           nvm_file:NVM file name (charp)
parm:           bt_coex_active:enable wifi/bt co-exist (default: enable) (bool)
parm:           led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking, 3=Off (default: 0) (int)
parm:           power_save:enable WiFi power management (default: disable) (bool)
parm:           power_level:default power save level (range from 1 - 5, default: 1) (int)

EDIT: Comme Bernhard l'a suggéré dans les réponses, j'ai essayé de forcer l'adaptateur à utiliser la commande echo "on" > /sys/class/bluetooth/hci0/device/../power/control. Alors que bluetooth était bloqué via rfkill, cela semblait n'avoir aucun effet et hciconfig hci0 up a répondu que l'appareil était toujours bloqué. Lorsque Bluetooth a été débloqué à l’aide de rfkill, /sys/class/bluetooth/hci0 n’existe pas et la tentative de l’activer manuellement échoue. J'ai également essayé d'ajouter ceci à /etc/rc.local, et il n'y avait aucune différence apparente par rapport à l'exécution des commandes en tant que root sur la console.

EDIT: J'ai envoyé un courrier électronique aux développeurs de réseaux wifi d'Intel, qui ont émis cette réponse extrêmement utile:

Hello,

I am afraid you are asking the wrong people. We are WiFi people and not Bluetooth.

Thanks,
(name removed)

Je vais tenter de pirater moi-même les pilotes Bluetooth pour voir si je peux en tirer plus d'informations de débogage.

Quelqu'un a-t-il des suggestions pour m'aider? Quelqu'un en at-il déjà fait l'expérience? Y a-t-il des utilisateurs Ubuntu possédant un ASUS UX301LA qui pourraient avoir des conseils?

Faites-moi savoir quelles autres informations pourraient être utiles, et je les posterai. Je ne voulais tout simplement pas surcharger ce premier message de données inutiles.

13.10bluetoothasusintel-wirelessrfkill
6
PaSTE

J'ai aussi UX301LA et je cours maintenant 14.10. J'ai eu le même problème, mais j'ai découvert une solution de contournement qui n'est pas idéale, mais qui fonctionne pour le moment.

Fondamentalement, il semble que le module asus-nb-wmi n’est pas totalement compatible avec ce matériel. Bien que le problème semble exister beaucoup plus profondément, le blocage de ce module empêche la création de nouvelles entrées rfkill correspondant au WiFi et au Bluetooth, puis l’état par défaut après le démarrage correspond au fonctionnement du WiFi et du Bluetooth (même avec l’USB 3.0). Le commutateur F2 reste toujours allumé quand Bluetooth fait disparaître, mais lorsqu'il est éteint (par défaut après le démarrage), il ne désactive pas le WiFi, alors que le périphérique Bluetooth apparaît. L'inconvénient est que les touches Fx cessent de fonctionner lorsque le module est bloqué car elles sont également prises en charge par ce module. Pour obtenir cet effet, ajoutez simplement blacklist asus-nb-wmi à /etc/modprobe.d/blacklist.conf

Une meilleure solution consisterait à signaler le bogue en amont ou à changer la source du module pour désactiver la gestion du wifi/bluetooth tout en gérant d'autres clés Fx.

1
Andrzej Pronobis

Le même problème se produit avec mon Lenovo T440. Je n'ai pas de solution pour le moment, mais il semble que nous sommes affectés par un bogue du noyau (une discussion à ce sujet peut être trouvée ici ).

Ajouter

echo "on" > /sys/class/bluetooth/hci0/device/../power/control

sur /etc/rc.local semble aider un peu, mais la connexion à ma souris Bluetooth est toujours instable.

0
Bernhard

Jetez un oeil à: /usr/share/gnome-bluetooth/pin-code-database.xml

Votre souris existe-t-elle là-bas (recherche à l'aide de l'OUI, qui est "l'identificateur unique OEM", qui correspond aux 3 premiers octets de l'adresse MAC de la souris. Par exemple, si l'adresse MAC de votre souris est AA: BB: CC: DD: EE : FF, alors le OUI est "AA: BB: CC")?

S'il existe déjà, assurez-vous qu'il ressemble à ceci:

(notez les deux points suivants: "AA: BB: CC * : *" - ne le laissez pas).

S'il n'existe pas déjà, ajoutez-le.

En outre, je ne sais pas si cela est lié, mais il existe un problème bien connu avec le processeur Intel 7260 WiFi (déconnexions sporadiques fréquentes). Pour contourner le problème du WiFi, j'ai constaté que la seule chose qui fonctionne est la désactivation de 802.11n:

  1. Terminal ouvert.
  2. Sudo vi /etc/modprobe.d/wifi-disable11n.conf
  3. Ajouter cette ligne: options iwlwifi 11n_disable = 1
  4. Sauvegarder et redémarrer.

Je prends juste un onglet dans le noir, mais ça vaudrait le coup (IMHO).

0
TheUnknownHobo