Raspberry Pi:Типовые проблемы/Не работает USB-девайс? Кликай тут!

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Перевод: Максим Кузьмин
Проверка/Оформление/Редактирование: Мякишев Е.А.


// в процессе обработки

Не работает USB-девайс? Кликай тут![1]

Если вы используете одну из поздних моделей Raspberry Pi, и у нее при этом не работают USB (и Ethernet), дело в том, что вы используете устаревшее ПО – просто обновите SD карту более новой версией NOOBS. В данном случае должна подойти любая версия, начиная от v1.3.8 (выпущенной 22 июня 2014), но лучше, разумеется, всегда следить за тем, чтобы на Pi стояло самое последнее ПО.

USB-возможности Raspberry Pi не так велики, как у ПК. У «малинки» они обеспечиваются хост-контроллером On-The-Go – как правило, его можно найти на мобильных телефонах в качестве порта для зарядки или подключения к ПК, а также на ТВ-приставках в качестве порта для USB-флэшки. И хотя технически Pi способна поддерживать все функции USB2.0 и USB1.1, эта задача имеет известные ограничения. Кроме того, не все USB-девайсы одинаковы – многие из них не отвечают тем или иным USB-требованиям. То есть, иной USB-девайс может отлично работать с ПК, но если его поведение не соответствует определенным требованиям, то при работе с Raspberry Pi могут возникнуть проблемы. Впрочем, как выяснилось в дальнейшем, эту проблему тоже можно решить.

Самостоятельное решение проблем

Вы обновились?

USB-драйвер и ядро взаимодействуют очень часто. Поэтому вам надо воспользоваться

sudo rpi-update

, чтобы установить на Pi самую последнюю прошивку и ядро – это обновление будет содержать множество патчей, которых нет в дефолтных версиях Raspbian. Если вы используете другой дистрибутив, то полезную информацию о том, как его обновить, можно найти в различных гайдах или на сайте этого дистрибутива.

Вас видно?

Если USB-девайс не работает, самый первый шаг – это выяснить, видит ли его Raspberry Pi. Для этого введите в терминале команды

lsusb

и

dmesg

. Первая отображает список всех девайсов, подключенных по USB, причем независимо от того, распознаются они или нет. Вторая отображает буфер сообщений ядра, но после загрузки Pi он может быть довольно большим, поэтому введите команду

sudo dmesg -C

, затем воткните девайс и снова напишите

dmesg

, чтобы увидеть новые сообщения.

Вот пример с USB-флэшкой:

pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 05dc:a781 Lexar Media, Inc.
pi@raspberrypi ~ $ dmesg

... Все, что произошло ранее ...

[ 8904.228539] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[ 8904.332308] usb 1-1.3: New USB device found, idVendor=05dc, idProduct=a781
[ 8904.332347] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8904.332368] usb 1-1.3: Product: JD Firefly
[ 8904.332386] usb 1-1.3: Manufacturer: Lexar
[ 8904.332403] usb 1-1.3: SerialNumber: AACU6B4JZVH31337
[ 8904.336583] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[ 8904.337483] scsi1 : usb-storage 1-1.3:1.0
[ 8908.114261] scsi 1:0:0:0: Direct-Access     Lexar    JD Firefly       0100 PQ: 0 ANSI: 0 CCS
[ 8908.185048] sd 1:0:0:0: [sda] 4048896 512-byte logical blocks: (2.07 GB/1.93 GiB)
[ 8908.186152] sd 1:0:0:0: [sda] Write Protect is off
[ 8908.186194] sd 1:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 8908.187274] sd 1:0:0:0: [sda] No Caching mode page present
[ 8908.187312] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 8908.205534] sd 1:0:0:0: [sda] No Caching mode page present
[ 8908.205577] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 8908.207226]  sda: sda1
[ 8908.213652] sd 1:0:0:0: [sda] No Caching mode page present
[ 8908.213697] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 8908.213724] sd 1:0:0:0: [sda] Attached SCSI removable disk

В данном случае в секции dmesg не замечено сообщений об ошибках, а флэшка определена как USB-накопитель. Впрочем, если бы у флэшки не было драйвера, то этот пример, скорее всего, ограничился бы первыми шестью строчками (в секции dmesg).

Если USB-девайс не определяется, то проблемы могут быть в следующем:

  • Питание. Возможно, дело в том, что USB-порты Raspberry Pi не могут дать достаточно электроэнергии для «кормления» девайсов, требующих по 500 миллиампер. Решение – качественный USB-хаб с собственным питанием. При этом надо иметь в виду, что в рекламе некоторых девайсов указываются одни требования к электропитанию, а на самом деле оказываются другие – это особенно касается беспроводных LAN-адаптеров и USB-накопителей. Кроме того, производители USB-хабов, в свою очередь, тоже могут завышать показатель мощности, выдаваемой их продуктами. Также имеет смысл проверить USB-девайс с другим источником питания – если результат тот же, то питание из списка проблем можно исключить.
  • Много хабов. Количество хабов, которые можно последовательно подключить к Raspberry Pi, ограничено. Если ваш девайс, будучи включенным в многопортовый хаб, отказывается работать, воспользуйтесь командой чтобы отобразить «дерево», иллюстрирующее то, как устройства физически подключены друг к другу. К слову, в модели B всегда будет как минимум один хаб, потому что Ethernet-чип – это, по сути, 3-портовый хаб и USB-Ethernet девайс.
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
 |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
     |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
     |__ Port 3: Dev 5, If 0, Class=stor., Driver=usb-storage, 480M

Хабы бывают разными, в том числе и низкой ценовой категории. В частности, встречаются такие, что сочетают в себе два маленьких (как правило, 4-портовых) хаб-чипа – это позволяет сделать хаб на 7-10 портов, и он будет отображаться в дереве как дополнительный шаг. Это значит, что USB-девайсы будут работать не со всеми портами хаба, а лишь с несколькими первыми, т.е. теми, которые подключены через первый хаб-чип. Raspberry Pi поддерживает до трех последовательно подключенных хаб-чипов типа USB2.0, включая хаб внутри Ethernet-порта. Попробуйте попереставлять USB-устройства из одного порта в другой, чтобы узнать, какие из них являются рабочими.

Может, нет драйверов?

Если девайс определился, но все равно не работает, то, вероятно, к нему просто не установлены необходимые драйверы. Попробуйте поискать их в сети по производственному названию девайса или по USB ID, которое было отображено в lsusb (например, 05dc:a781). Ваш девайс, возможно, не будет поддерживаться дефолтными драйверами Linux, поэтому вам надо будет их загрузить либо спрограммировать самому.

Слабая производительность, но ошибок в dmesg не наблюдается.

Во-первых, надо убедиться, что причиной проблемы является именно сам USB-девайс. Некоторые из них становятся «капризными», когда перегреются. Например, беспроводные LAN-адаптеры при постоянном использовании могут очень сильно разогреться – попробуйте отключить девайс, дать ему несколько минут отдохнуть, а затем подключить снова. Кроме того, на его производительность могут влиять другие USB-девайсы – к примеру, беспроводные устройства, использующие ту же сеть или USB-шину. Оставьте на Pi необходимый минимум USB-девайсов и попробуйте снова.

Девайс отключается или постоянно переподключается.

Причиной этой проблемы, опять же, может стать недостаточное электропитание, так что этот вопрос нужно проверить как можно тщательней. Если дело не в питании, то это может быть симптомом того, что девайс выдает слишком много ошибок, из-за чего Linux перезагружает девайс. Попробуйте переставить USB-девайс в другой порт хаба (как описывалось выше).

Просим помощи

Есть возможность, что кто-то уже столкнулся с вашей проблемой и написал о ней на форуме. Так что имеет смысл поискать, и не только на форуме, но и в Google.

Если ваша проблема затрагивает какой-то конкретный девайс, будьте готовы предоставить любую полезную информацию об этом девайсе, включая всю выдачу из

lsusb -v

,

dmesg

и

uname -a

. Хорошие посты с просьбой о помощи, как правило, содержат много исчерпывающей информации о том, что вы сделали, чего ожидаете и что на самом деле произошло.

Общая информация

  • На Raspberry Pi всего один корневой USB-порт. Это значит, что пропускная способность шины USB2.0 поделена между всеми подключенными девайсами. Если вы одновременно используете несколько девайсов, требующих высокой пропускной способности, то будьте готовы к тому, что некоторые из них будут работать медленнее. К слову, драйвер Pi оснащен особым механизмом, оценивающим качество передачи данных – он более оперативен, чем обычная информация о трафике, идущем в/от подключенного USB-накопителя или Ethernet-контроллера SMSC 9512.
  • На Raspberry Pi есть мягкое ограничение на количество единовременно действующих USB-девайсов. Pi может поддерживать лишь до восьми одновременно проходящих USB-операций. Впрочем, это не такое уж строгое ограничение, поскольку драйвер, управляя восемью доступными USB-каналами, пытается сделать их работу как можно более оптимальной, и в большинстве случаев вы можете подключить к Pi и использовать более восьми девайсов, поскольку когда один девайс завершает поставленную перед ним задачу, то этот канал освобождается для другой работы. Таким образом, более сильным ограничением в процессе работы будет выступать, как правило, не количество подключенных девайсов, а общая пропускная способность USB2.0, о которой говорилось пунктом выше. Тем не менее, девайс, надолго «оккупировавший» какой-то конкретный канал, может испытывать проблемы в производительности.
  • Высокоуровневые части USB-протокола реализованы в ПО. Устройства типа On-the-Go обладают более упрощенной USB-поддержкой, чем аналогичное ПК-оборудование. Чтобы компенсировать этот перекос, USB-драйверу dwc_otg приходится выполнять больше работы, чем его «собрату» EHCI. Это особенно важно при использовании дробных операций между девайсами USB1.1 на шине USB2.0. Впрочем, дело не стоит на месте и в данный момент ведутся работы, чтобы сделать это ПО как можно более эффективным и быстрым (см. пункты о реализации FIQ).
  • FIQ (быстрые прерывания). Существующий драйвер dwc_otg уязвим к задержкам прерывания, генерируемым другими частями ядра Linux – если выключить прерывания, выполнение операций занимает очень долгое время. Поэтому, чтобы драйвер стал менее чувствителен к другим действиям ядра Linux, были внедрены так называемые «быстрые прерывания» (FIQ или fast interrupts). Их задача – обеспечить надежное выполнение определенных типов USB-операций (именуемых «дробными» операциями – они осуществляются между девайсом USB1.1 и шиной USB2.0), для чего используется механизм выбора по приоритету, имеющийся у процессора ARM. Это решает, к примеру, большую часть проблем с пропущенными нажатиями на клавиатурные кнопки. Впрочем, текущая реализация этой функции имеет некоторые ограничения (см. раздел «Известные проблемы»).

Известные проблемы (все они в данный момент исправляются)

  • Цепь USB-хабов может иметь лишь определенную глубину. Между USB-девайсом и корневым портом Pi может работать не более пяти последовательно подключенных хабов типа USB2.0. При этом девайсы USB1.1 должны работать не более, чем с четырьмя хабами.
  • Высокоскоростные, широкополосные, изохронные операции подвержены потере данных. Среди типичных симптомов – искаженное видео от веб-камер, передающих несжатые данные, а также искажения при передаче потокового HD-видео от DVB-адаптеров. По большей части это происходит из-за того, что задержка прерывания не дает USB-ядру запрашивать (и передавать) изохронные пакеты на желаемой скорости. Кроме того, изохронные передачи крайне нуждаются в драйвере dwc_otg, который способен снизить чувствительность, когда система работает с большим количеством изохронного трафика.
  • Опция fiq_split_enable=1 мешает записи и проигрыванию аудио. И хотя FIQ оснащен множеством механизмов для того, чтобы «дробные» операции осуществлялись без ошибок, у него есть свои ограничения. По большей части они касаются недостаточной поддержки для изохронной передачи входных данных, требующей больше одного пакета (речь, например, об аудиозаписи и некоторых очень старых веб-камерах). Ограничение для аудиозаписи – не выше 32 КГц 16-бит стерео. В данный момент FIQ не умеет обрабатывать многопакетную изохронную передачу выходных данных, оставляя эту работу для USB-драйвера. Поэтому, если вам требуется, к примеру, аудиозапись качеством выше 32 КГц 16 бит стерео, эту опцию нужно выключить при помощи строчки
    dwc_otg.fiq_split_enable=0
    
    в
    /boot/cmdline.txt
    
    . Впрочем, тогда на сцену выйдет другое ограничение (см. следующий пункт).
  • Дробные операции, которые объединяют в себе несколько пакетов, искажаются. Типичный симптом – фоновые помехи при аудиозаписи и выводе звука. Запись и проигрывание аудио требует многоэтапной дробной операции, точно спланированной и выполненной в правильном порядке и в правильное время. Если USB-драйвер пропустит отправку пакета дробной операции, эти данные, как правило, теряются. Чем больше битрейт и количество используемых аудиоканалов, тем сильнее искажение сигнала. Добавьте сюда задержку в загрузке Pi (через SD-карту или Ethernet), и помехи станут еще сильнее.
  • USB-хабы, работающие по принципу STT, отличаются плохой производительностью, если подключить к ним много девайсов типа USB1.1. У хабов есть механизм, отделяющий низко- и среднескоростные девайсы от высокоскоростных девайсов типа USB2.0. Его называют «передатчиком операции» (т.е. transaction translator или просто TT), и он отвечает за выполнение операций на скоростях USB1.1. Эти передатчики бывают двух видов – одинарными (STT или Single Transaction Translator, т.е. один передатчик на все порты; «дешевый» вариант) и множественными (MTT или Multiple Transaction Translator, т.е. у каждого порта свой передатчик). Таким образом, если воткнуть несколько USB1.1 девайсов в STT-хаб, то все эти девайсы будут работать через один единственный передатчик. Причем FIQ делает эффект от «правила очереди» еще более значимым, когда общается с девайсом в обход TT. То есть эксклюзивный доступ к передатчику операции означает, что STT-хабы имеют ограничение на количество девайсов, которыми можно пользоваться одновременно. В противном случае это чревато потерей пакетов из-за конфликтов в планировании. Звуковые аудиоустройства особенно уязвимы, если делят TT с другими USB1.1 девайсами. Поэтому мы настоятельно рекомендуем пользоваться USB-хабами с несколькими TT – эту информацию можно узнать из
    lsusb -v | less
    
    , промотав до списка для внешнего хаба.

Обходные решения

  • Если используете звуковые USB-устройства, попробуйте выключить у драйвера опцию
    fiq_split
    
    , написав в
    /boot/cmdline.txt
    
    строчку
    dwc_otg.fiq_split_enable=0
    
    .
  • Если используете звуковые USB-устройства, попробуйте воспользоваться опцией
    snd-usb-audio nrpacks=1
    
    в
    /etc/modprobe.d/options
    
    .
  • Еще один продвинутый прием для звуковых устройств – попробуйте удалить конечную точку HID, которую используют многие из этих девайсов (для регулирования громкости, выключения звука и т.д.). Сделать это можно, «отвязав» драйвер usb-hid от девайса. Более подробно об том можно прочитать на форуме Ubuntu, но учтите, что вам нужно будет адаптировать описанный там метод под свои нужды.
  • У вебкамер и девайсов для потокового видео искажение можно уменьшить, снизив настройки разрешения. Или можно переключиться на поток сжатых MPEG-данных.
  • Для устройств, которые по-прежнему отказываются работать, крайним средством будет вписать строчку
    dwc_otg.speed=1
    
    в
    /boot/cmdline.txt
    
    . Это снизит скорость шины до скорости USB1.1, т.е. до 12 Мбит/сек. Впрочем, если активировать эту опцию, то Ethernet будет работать крайне медленно.

См.также

Внешние ссылки