Проблемы с Bluetooth после сна в OS X Yosemite (10.10)

Кажется, у меня постоянно возникают проблемы с подключением Bluetooth, особенно после пробуждения моего Macbook Pro из долгого сна.

У меня есть динамик, который автоматически отключается после определенного периода бездействия, и в моем случае я обычно использую ноутбук, включаю динамик, и когда драйвер Bluetooth работает нормально, они автоматически подключаются.

Однако проблема заключается в том, что мои периферийные устройства Bluetooth не переподключаются, если мой Macbook только что проснулся от долгого сна.

После поиска я нашел этот скрипт для перезапуска расширений ядра bluetooth , но, похоже, он не работал на Yosemite.

Вот что sudo tail -f /var/log/system.logдало мне после выполнения а kextloadи kextunload(имя хоста и имя пользователя отредактированы):

Nov 17 07:50:11 {redacted} sudo[8118]: username: TTY=ttys000 ; PWD=/Users/username; USER=root ; COMMAND=/sbin/kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:11 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:11 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:11 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800 
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][initHardwareWL] -- failed -- calling DoDeviceReset (kBluetoothControllerResetHub) -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][DoDeviceReset] -- thread_call_enter1 (mReEnumerateOrResetThread) -- reEnumerateOrReset (0xffffff8213ac3ae0) = 2 --  returned FALSE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Error!! -- Something went wrong in the setup process. Could not communicate with Bluetooth Transport successfully -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- entering -- param0 = 0xffffff806a870800, param1 = 0x2 -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- entering -- reEnumerateOrResetIn = 2 -- this = 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- in our workloop -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- parameter is valid -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- reEnumerateOrReset = 2 -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- calling myHub->ReEnumerateDevice() -- gEnumerateCounter = 1 
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHostControllerUSBTransport][ReEnumerateOrReset] -- exit; error = 0x0000 (kIOReturnSuccess)
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][ReEnumerateOrResetThreadEntry] -- exiting -- 0x0800
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe
Nov 17 07:50:12 {redacted} kernel[0]: IOBluetoothUSBDFU::probe ProductID - 0x821D FirmwareVersion - 0x0147
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHostControllerUSBTransport][start] -- completed -- result = TRUE -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: **** [BroadcomBluetoothHostControllerUSBTransport][start] -- Completed -- 0x0800 ****
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController][staticBluetoothTransportShowsUp] -- Received Bluetooth Controller register service notification -- 0x0800 
Nov 17 07:50:12 {redacted} kernel[0]: [IOBluetoothHCIController::setConfigState] calling registerService
Nov 17 07:50:12 {redacted} kernel[0]: **** [IOBluetoothHCIController][ProcessBluetoothTransportShowsUpActionWL] -- Connected to the transport successfully -- 0xe300 -- 0x0800 -- 0x0800 ****
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.595 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.617 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.637 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.657 : SDStatusMonitor::kStatusBluetoothPowerChanged
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.659 : BTLE scanner Powered Off
Nov 17 07:50:12 --- last message repeated 2 times ---
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663673 AM [AirPlay] BTLE client stopping to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} blued[62]: hciControllerOnline; HID devices? 0
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.663868 AM [AirPlay] BTLE client starting to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Starting Handoff scanning
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664336 AM [AirPlay] BTLE client stopped to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} coreaudiod[360]: 2014-11-17 07:50:12.664753 AM [AirPlay] BTLE client started to browse for AirPlay Solo Target Presence.
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.664 : Stopping Handoff advertising
Nov 17 07:50:12 {redacted} sharingd[367]: 07:50:12.665 : BTLE scanner Powered On
Nov 17 07:50:12 {redacted} blued[62]: hostControllerOnline - Number of Paired devices = 2, List of Paired devices = (
      "00-0c-8a-dd-fd-88",
      "84-38-35-ec-1c-ea"
  )
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::message - kIOUSBMessagePortHasBeenReset.
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::checkStatus - received Status Packet, Payload 2: device was reinitialized
Nov 17 07:50:13 {redacted} hidd[74]: MultitouchHID: device bootloaded
Nov 17 07:50:13 {redacted} kernel[0]: AppleUSBMultitouchDriver::_deviceGetReport - DeviceRequest for reportID 0xc8 returned with result 0xe000404f - retrying

uname -a вывод (имя хоста отредактировано):

$ uname -a
Darwin {redacted} 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

Кто-нибудь из вас видел эту проблему раньше? Любая помощь будет оценена.

После обновления до Yosimite у меня были проблемы с повторным подключением клавиатуры и трекпада Bluetooth.

Сначала попробуйте это: Откройте терминал и выполните 2 команды:

sudo kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport

sudo kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport

Мне нужно было бежать только один раз. Если позже Bluetooth снова сломает 2 варианта, просто снова запустите выше или вы можете создать решение в один клик с помощью простого приложения с помощью Automator:

1. Найти (поиск Spotlight) и запустить Automator
2. Нажмите «Новый документ» внизу
3. Выберите «Приложение» для нового типа файла.
4. Нажмите на «Утилиты» из списка
5. Дважды щелкните «Запустить AppleScript»

6. Замените (* Ваш скрипт идет сюда *) на:

   do shell script "kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport; 
   kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport" with administrator privileges
   

7. Нажмите play, чтобы проверить (запрос пароля)
8. Файл-> Сохранить на рабочем столе или где угодно

Запустите приложение Automator, когда устройства Bluetooth не будут подключаться

Решение Mikaey на форуме поддержки Apple:

1. Выключи свой WiFi
2. Попробуйте повторно подключиться к вашим устройствам Bluetooth ( должно работать )
3. Включите WiFi снова

Это решило проблему для меня.

После попытки запустить сценарии, предложенные другими ответами, выгрузить и перезагрузить как kext, так и демон bluetooth, мой bluetooth все еще не отвечал.

Тем не менее, я обнаружил, что если Yosemite спит с работающим VMWare и bluetooth не работает, когда ОС пробуждается, закрытие VMWare устраняет проблему.

Кажется, что драйверы в VMWare не всегда правильно обрабатывают процесс сна / пробуждения.

- ОБНОВЛЕНИЕ: эта проблема НЕ исправлена ​​в OSX 10.11 El Capitan -

Следующее является альтернативой решению Automator, опубликованному webaholic, для тех, кто, как и я, считает неудобным повторный ввод пароля (скорее всего, вы только что ввели его для входа в систему после пробуждения Mac).

Сначала в терминале создайте скрипт, который перезагружает подсистему Bluetooth:

cat > bt_restart <<END
#!/bin/sh
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport && \
kextload   -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
END
chmod +x bt_restart

Во-вторых, сделайте root его владельцем и переместите его в / sbin:

sudo chown root:wheel bt_restart
sudo mv bt_restart /usr/local/sbin

В-третьих, добавьте команду в список команд NOPASSWD в sudoers:

echo -e "\n\n# Restart bluetooth without password\n$USER ALL=(ALL) NOPASSWD: /usr/local/sbin/bt_restart" | EDITOR='tee -a' sudo visudo

Наконец, создайте скрипт на рабочем столе, который вызывает bt_restart:

echo '#!/usr/bin/sudo /usr/local/sbin/bt_restart' > ~/Desktop/"Restart Bluetooth"
chmod +x ~/Desktop/"Restart Bluetooth"

Готово! Просто дважды щелкните трекпадом вашего ноутбука (или мышью USB) на перезагрузке Bluetooth на рабочем столе.

У меня была та же самая проблема, и я думаю, что я нашел возможную причину проблемы. Моя мышь называлась «Мышь моего имени» с апострофом, возможно, это было причиной ошибок.

Я изменил имя, чтобы избежать использования пробелов и специальных символов, теперь он называется просто «mymouse», и у меня, похоже, больше нет проблем.

У меня все еще есть эта проблема в macOS Sierra. Ссылка @ Tyilo выше на его суть дала мне отправную точку. Но я также хотел использовать homebrew для установки sleepwatcher, и файлы plist не были настроены должным образом из коробки. Так что я долго играл и придумал сценарий, который заставил меня работать надежно.

brew install sleepwatcher
sudo touch /etc/rc.sleep
sudo tee -a /etc/rc.wakeup <<EOF
#!/bin/sh
# Sleepwatcher script to get bluetooth working after the mac wakes up
# Got this approach from https://gist.github.com/Tyilo/c92684d277acb62272b5
kextunload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
kextload -b com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport
EOF
sudo chmod +x /etc/rc.wakeup
brew services start sleepwatcher
sudo tee -a /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>de.bernhard-baehr.sleepwatcher</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/sbin/sleepwatcher</string>
        <string>-V</string>
        <string>-s /etc/rc.sleep</string>
        <string>-w /etc/rc.wakeup</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>
</plist>
EOF
sudo launchctl load /Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-custom.plist

Благодаря Tyilo из комментариев к принятому ответу, я изменил его скрипт, чтобы установить sleepwatcher и добавить в скрипт некоторый код, который не только выгружает драйвер Bluetooth ( com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport), но и перезапускает bluedдемон Bluetooth от Apple.

Сценарий можно найти здесь: https://gist.github.com/timgws/fc63aeca6a248bbb25ff

Запуск этого решил все проблемы для меня.

Подводя итог, вот список вещей, упомянутых здесь, в ссылках отсюда, в аналогичных темах на других сайтах, или даже составленных мной, исходя из этих других. Я пробовал все это, по одному и во многих комбинациях. Казалось, что все они работают по крайней мере один раз; все провалились хотя бы один раз.

• новые мышиные батареи
• удалить и переназначить мышь
• выключить WiFi и мышь; подключить Bluetooth-мышь; восстановить WiFi
• отключить WiFi, мышь и VPN; подключения; восстановить
• удалить Bluetooth PAN; подключения
• kextunload / загрузка USBTransport; подключения
• провод kextunload для лунатика; спать; бодрствования; подключения
• отключите все разъемы USB (черт возьми, все разъемы); подключения
• выйти; авторизоваться; подключения
• запустить снова; авторизоваться; подключения
• сбросить SMC (что предполагает «выключение»); запустить снова; войти подключиться
• выключить виртуальный хостинг (например, VMWare, Parallels или VirtualBox)

Я предпочитаю держать этот список под рукой и использовать «все вышеперечисленное».

Я думаю, что единственное, что здесь точно, это то, что где-то задействована большая доза «случайного», возможно, гонка среди всех этих драйверов для сетей, псевдосетей, многоуровневых сетей, виртуальных сетей и прокси-сетей. В этом случае, вероятно, это не просто вина Apple, потому что эти драйверы поступают из разных источников.

Конечно, когда-то известная репутация Apple «просто работает» во многом была основана на запрете именно такого рода сталкивающегося разнообразия.

Сознавая, что это довольно старый пост сейчас, но его сводит с ума задержка, которую я получал после пробуждения во время сна до того, как Magic Trackpad стал пригодным для использования… может легко пройти хорошие 30 секунд. Перепробовал большинство / все советы и подсказки, которые я мог найти, чтобы получить очень мало эффекта.

Однако я только что попытался переместить значок Bluetooth в строке меню (CMD ALT Drag) из его нормального положения (около 7-го дюйма) во 2-е (как считается справа), то есть рядом с меню Spotlight.

Так далеко? ... проблема ушла!

Не уверен на 100%, почему это так, но подозреваю, что это может быть связано с порядком, в котором задачи из этих пунктов в строке меню RHS выполняются после пробуждения, то есть те, которые ближе к RHS, имеют более высокий приоритет?

Это займет всего пару секунд, поэтому, если у вас также есть эта проблема - может быть стоит попробовать?

(iMac 27 "i7 / OS X 10.10.5)

JH

Большая часть предложений, которые я прочитал, казалась немного сложной для чего-то такого простого. Решил заняться нубским подходом:

1. Перешли к Системным настройкам / Мышь / Настройка Bluetooth Mouse
2. На экране появилось сообщение «Мышь не найдена» и начался поиск.
3. Выключил мою мышь, затем снова включил (решение Windows для множества проблем).
4. Он нашел мою мышь.

Похоже, что kextunloadкоманды на самом деле больше не работают на High Sierra. Тем не менее , есть сторонний инструмент командной строки, который делает то же самое, и он работает: https://github.com/toy/blueutil - вы можете настроить скрипты, упомянутые здесь, чтобы использовать blueutilвместо них, или есть даже полноценное решение ( очень похоже на то, что мы уже видели на этой странице): https://gist.github.com/ralph-hm/a65840c4f5e439b90170d735a89a863f

В этой статье Майкла Куммера сообщается о довольно исчерпывающем списке неудачных попыток исправить проблемы с Bluetooth на Mac, и, наконец, предлагается компромиссное решение путем отключения функции handsoff, которая кажется работающей: https://michaelkummer.com/technology/mac-bluetooth-issues-affect -keyboard-трекпад /

Также видно по адресу https://www.forbes.com/sites/bradmoon/2017/07/13/this-trick-may-solve-your-mac-bluetooth-connectivity-issues/#6fefb3f45196

Переустановите MacOS.

На самом деле это не решение проблемы, но я просто хочу поделиться своим опытом, чтобы дать надежду тем, кто сталкивается с той же проблемой, что и я, - что это, возможно, все еще не проблема с оборудованием или проблема с помехами Wi-Fi, которая может быть более дорогостоящей. или хлопотно решить эту переустановку MacOS.

Что я испытал: после того, как мой Macbook Pro 2015 года проснулся от сна, он не смог подключиться к устройствам Bluetooth. Проблема усугублялась со временем, от первоначального небольшого неудобства (например, отключение и повторное включение модуля Bluetooth или Wi-Fi может исправить это), а затем к огромной боли (например, требуется перезагрузка с сбросом SMC / PRAM).

Симптом или побочный эффект, который может быть связан с этим, заключается в том, что компьютеру иногда требуется слишком много времени (10 секунд), чтобы проснуться.

Переустановка (чистой) MacOS была моим последним средством, но, похоже, она просто работает. После переустановки я не заметил никаких проблем или сбоя с Bluetooth, Wi-Fi или сна.

Отказ от ответственности: вероятно, существует какое-то правильное исправление, которое может достичь того же эффекта, который может быть, а может и не быть обнаружен. Кроме того, переустановка ОС всегда сопряжена с риском потери данных и производительности, которые следует оценить.

Новое обновление: это было без проблем в течение недели. Но тогда проблема блютуса, кажется, иногда возвращается. В течение недели я не слишком много работал с системой, кроме установки какого-то очень распространенного программного обеспечения и пакетов, в основном через Homebrew.

Основываясь на предложениях других людей, я создал простой сценарий оболочки для сброса Bluetooth. Смотрите суть для деталей.

Упрощенная версия (зависит от blueutilварева):

blueutil -p 0
networksetup -setairportpower en0 off
sleep 3
networksetup -setairportpower en0 on
sleep 3
blueutil -p 1

Он выключает Bluetooth, выключает Wi-Fi, снова включает Wi-Fi и, наконец, снова включает Bluetooth.

Попробуйте щелкнуть мышью после того, как ваш Mac выйдет из сна.

Похоже, это быстрее связало мою Magic Mouse 2 с Mac Mini под управлением macOS Sierra (10.12.2).