Сбросить usb порты linux

Обновлено: 21.11.2024

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

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

Оглавление

Информация о USB-устройствах

Прежде чем мы начнем, давайте посмотрим, как получить информацию о USB-устройствах, подключенных к системе. Для этого мы можем использовать lsusb, который прямо сейчас выведет список подключенных устройств. Я привожу примеры того, что сейчас получаю на своем компьютере, но, возможно, оно сильно отличается от того, что вы получаете:

Если нам нужна дополнительная информация, мы можем использовать модификатор -t, который покажет нам вывод в виде дерева с информацией о модулях:

Если нам нужно гораздо больше информации, мы можем использовать lsusb -v (вывод очень большой), мы также могли бы, например, узнать максимальную мощность, подаваемую на устройство, следующим образом:

Другие очень полезные команды — usb devices, hwinfo или, например, если у нас есть путь к устройству (внутри /dev/), мы можем запросить у системы всю возможную информацию о нем и подсистемах, которые оно должно проходить через. Например, если мы подключаем жесткий диск USB, чтобы мы могли видеть, как используется устройство, нам нужен драйвер SCSI (для того, чтобы быть /dev/sdX), также нам нужен драйвер USB-накопителя, который работает через USB-порт, который принадлежит концентратору, который подключается к порту PCI среди других промежуточных систем. Все, что мы могли видеть с

Если мы хотим рискнуть, мы также можем войти в /sys/bus/usb и посмотреть все, что там есть, мы увидим много информации, но, к счастью, приведенные выше команды классифицируют всю эту информацию.

Права доступа и устройства

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

В этом выводе мы увидим, что устройство, с которым мы работаем, — это ndc (sdc1 и sdc2 — это разделы на этом диске). Для примеров я буду использовать это устройство, в вашем случае вам нужно будет посмотреть, какое у вас есть.

В приведенных ниже примерах я буду использовать sudo для выполнения команд с привилегиями root. Хотя было бы достаточно иметь пользователя с достаточными правами. Если мы хотим увидеть необходимые привилегии, просто выполните ls для устройства:

Там мы видим, что владельцем является root и группа disk. Достаточно иметь пользователя, принадлежащего к групповому диску.

Способ 1. Обращайтесь с ним как с CD/DVD

Это самый простой из всех. Конечно, если вы использовали GNU / Linux в течение многих лет, когда вы работали с CD-ROM или DVD, вы использовали команду извлечения. Итак, команда eject использовалась для открытия компакт-диска, а команда eject -t использовалась для закрытия лотка. Хорошо, если мы сделаем это до USB-устройства:

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

Способ 2. Отключение и виртуальное подключение

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

В данном случае /dev/sdc — это мое устройство, и с помощью этой команды оно имитировало виртуальное отключение питания.

Проблема в том, что сейчас /dev/sdc не существует, более того, если мы посмотрим на dmesg, то получим что-то вроде этого:

Поэтому, если мы попробуем методом выбрасывателя, это не сработает. Примечание. Я выделил USB 1–5, и вскоре мы увидим, почему.

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

Как теперь подключить ток?

Мы должны сделать вызов на порт USB, для этого есть проект под названием hub power (я ссылаюсь на форк оригинального проекта, потому что здесь исправлена ​​​​ошибка, которая может снимать ток с большего количества устройств, а не только тот, который мы хотим).Есть и другие проекты (например, uhubctl), но у него нет зависимостей, когда мы переходим к компиляции, это также просто файл hubpower.c.
Сначала мы его компилируем,

Теперь вы помните цифры, выделенные жирным шрифтом в dmesg? Что ж, мы собираемся их использовать, нам придется отключить устройство и снова подключить его, вот так:

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

Таким образом, мы снова увидим наше подключенное USB-устройство.

Если нам не нужна программа на C . У меня есть на Perl

Программу на C трудно скомпилировать и протестировать, если то, что мы собираемся сделать, очень просто, поэтому мы можем попробовать этот небольшой порт из 10 строк, сделанный на Perl:

Мы должны учитывать $ устройство, номер порта (в моем случае это было 5), это значение в шестнадцатеричном формате, поэтому 10 будет A, 11 будет B, 15 будет F, 16 будет 10. Мы также должны отслеживать устройство и шину, к которой мы обращаемся из /dev/bus/usb/001/001, числа должны идти с ведущими нулями, так как мы вызываем этот файл.

Как мы видим, ключ находится в ioctl(), это функция, которая манипулирует параметрами устройства из специального файла в файловой системе. Среди используемых шестнадцатеричных значений мы находим 0xC0185500, константу с именем USBDEVFS_CONTROL, с помощью которой мы будем отправлять команду управления на USB-устройство. Остальные коды относятся к запросу на отключение и подключение (более подробную информацию вы можете найти в программе, сделанной в С).

Способ 3. Скрытие и отображение устройства

Еще один способ отключить устройство:

И мы можем восстановить его, выполнив:

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

Способ 4. Авторизация устройства

Недостаток этого метода в том, что во многих системах можно временно отключить больше устройств, которые не только нужны нам, но и атакуют целый USB-концентратор. Например:

Что, конечно, мы можем запускать все подряд:

Мы должны быть осторожны, если к одному и тому же USB-порту подключено больше дисков (и почти всегда в наших компьютерах несколько USB-портов, чем те, которые мы видим, внутренне подключены к концентратору, поэтому существуют группы портов с тот же USB отец, как-нибудь поставь.

Способ 5. Перезагрузите подсистему USB

Если мы хотим перезапустить подсистему USB. То есть обновить все USB-устройства, например, отключив и подключив их все, с одной стороны, мы можем загрузить и перезагрузить модуль ядра USB:

Несмотря на то, что некоторые дистрибутивы, включая последние версии Ubuntu и производные, имеют встроенные USB-модули, и их нельзя загрузить. С другой стороны, система может не позволить нам загрузить их, потому что они используются из-за других модулей (принтеры, хранилища, интерфейсные устройства и т. д.), и если мы начнем загружать модули и сломаем что-то, нам, возможно, придется перезапустить компьютер. в конце. Итак, по-другому мы можем сделать:

Чтобы найти наше устройство, мы можем сделать ls внутри /sys/bus/pci/drivers/xhci_hcd, появится несколько вещей, мы должны искать то, что выглядит так aaaa:bb:cc:dd.e. Ваш USB-порт может быть не xhci_hcd (USB3), а скорее ehci_hcd (USB2)

Содержание статьи соответствует нашим принципам редакционной этики. Чтобы сообщить об ошибке, нажмите здесь!.

Это может вас заинтересовать

14 комментариев, оставьте свой

Оставить комментарий Отменить ответ

Большое спасибо, Кристиан! Надеюсь, он был вам полезен.

В этой статье не сказано, что всякий раз, когда вы собираетесь поставить его, он находится на противоположной стороне от правильного, и вы должны перевернуть его. хехехе. Отличная статья.

Спасибо, Антонио Хуан! Ну смотри, ты не представляешь, сколько раз это случалось со мной, пока я пробовал все, что написал в посте! 🙂

Отлично. Превосходный предмет. Он должен быть озаглавлен: «Узнайте о системе Linux, просто отключив и вставив USB-накопитель». Поздравляем.
Привет из Малаги.

Ну да, я не знаю, начнет ли кто-то программировать на C и получать доступ к устройствам из этого поста! Также из Малаги !! Мы везде 🙂

Впечатляющая статья. Вы переборщили с таким материалом.

Большое спасибо друг. Запускаю в linux, конкретно в linux mint, и у меня следующая проблема: в консоли вижу, что мой телефон подключен к машине, а в файловом менеджере нет. И поэтому я не могу использовать его в качестве модема для подключения к Интернету. Что я могу сделать?

Есть телефоны, которые не позволяют подключаться в качестве модема, но вы можете использовать модем

Теперь я использую lsusb -v для проверки уровня мощности устройства, но он выдает 2 мА, что совершенно абсурдно. только светодиоды потребляют больше.

Я подключаю модем huawei E4 USB-8372G, однако максимальная мощность показывает 2 мА, что невероятно, теперь сомнения изменились и появились другие:
Является ли MaxPower атрибутом, который идет по умолчанию на устройстве или в ОС?
Это параметр максимальной мощности, которую выдаст usb порт?
В случае, если это параметр
Можно ли изменить этот параметр и установить его на максимальное значение, заданное портом USB (900 мАч-3.0 / 500 мАч-2.0)?
В случае, если это не параметр,
является ли это значение измерения потребления USB в реальном времени (маловероятно)?
Если это другой вариант, пожалуйста, объясните мне, так как я сомневаюсь в справочной информации.

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

lsusb -v 2> /dev/null | egrep "^ Шина | MaxPower | bDeviceClass | iProduct"

Шина 002 Устройство 006: ID 1a86: 7523 QinHeng Electronics HL-340 Адаптер USB-Serial
bDeviceClass 255 Конкретный класс поставщика
iProduct 2 USB2.0-Serial
MaxPower 96mA
Шина 002 Устройство 008: ID 12d1: 14 дБ Huawei Technologies Co., Ltd.
bDeviceClass 2 Communications
iProduct 2 HUAWEI_MOBILE
MaxPower 2mA

Универсальная последовательная шина (USB) — это значительное улучшение для всех компьютерных систем, позволяющее использовать универсальный тип подключения для различных типов устройств. Система Bus немного сложнее, чем многие могут себе представить. Иногда USB-устройства могут выйти из строя и требуют перезагрузки. Обычно это простая процедура перезапуска системы, но иногда это может быть серьезной проблемой. Есть лучший способ.

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

  • Тип коннектора — универсальный коннектор, не похожий на другие типы. Раньше последовательный, параллельный, видео и т. д. были разными типами разъемов.
  • Расширяемость — возможность поддерживать 127 устройств на одной шине.
  • Горячая замена — поддерживает подключение/удаление устройства при включенной системе.
  • Производительность: четыре скорости в зависимости от типа USB.
  • Низкая скорость — 1,5 Мбит/с для USB 1.0
  • Полная скорость — 12 Мбит/с для USB 1.1
  • Высокая скорость — 480 Мбит/с для USB 2.0
  • Сверхскорость — 5 Гбит/с для USB 3.0
  • Подключи и работай – поддерживаемые операционные системы могут определять тип устройства и при необходимости настраивать его.
  • Электропитание — при необходимости по шине.
  • Энергосбережение — возможность приостанавливать/возобновлять работу устройств, когда они не используются.
  • Простота: пользователям легко управлять оборудованием.
  • 1.x — открытый интерфейс хост-контроллера (OHCI)
  • 1.x — универсальный интерфейс хост-контроллера (UHCI)
  • 2.0 — улучшенный интерфейс хост-контроллера (EHCI)
  • 3.0 — расширяемый интерфейс хост-контроллера (xHCI)

Глядя на рис. 1, вы видите четыре шины USB. Они помечены от шины 1 до шины 4. Все эти основные устройства перечислены как «root_hubs» на порту 1. Корневые концентраторы всегда являются портом 1, а подключенные устройства перечислены на следующих портах, начиная со 2, по мере их подключения. Драйвер определяет драйвер Linux и обозначает стандарт USB (OHCI, UHCI, EHCI или xHCI). Число после «/» обозначает, сколько портов расположено на устройстве. Имейте в виду, что количество портов может не быть внешним портом. Например, шина 1 на рисунке 1 показывает, что она имеет шесть портов. Шина 1 определенно является USB 2.0, поскольку она указана в драйвере EHCI, а скорость шины указана как 480M. Все шины со 2 по 4 — USB 1.1 со скоростью 12 М.

ПРИМЕЧАНИЕ. Имейте в виду, что порт может быть подключен к корневому концентратору USB 1.x и 2.0. В случае сбоя корневого концентратора USB 2.0 порт, к которому он подключен, все еще может функционировать как порт USB 1.x. Мы можем изучить эту способность позже.

На рис. 2 показана система с семью шинами USB. Три шины — USB 2.0, а четыре — USB 1.1. Некоторые внутренние устройства, которые могут быть частью портов, могут включать:

  • Аудио
  • Видео
  • Сеть
  • Чипсеты
  • Картридеры
  • Оптические устройства
  • Внутреннее запоминающее устройство
  • Bluetooth

На рис. 3 показана система с тремя концентраторами USB. Шины 1 и 2 — это USB 2.0, а шина 3 — корневой концентратор USB 3.0. Помните, что корневые концентраторы указаны как устройство 1. Здесь вы можете видеть, что на шине 1 есть устройство 2, которое указано как «Intel» и является веб-камерой Intel. К шине 2 подключены два устройства как Устройство 2 и Устройство 3.Устройство 2 указано как «Syntek», то есть мышь. Устройство 3 – это устройство для чтения с несколькими флэш-памятью.

Возможно, вы смотрите на рис. 3 и думаете об идентификаторе. Каждое USB-устройство имеет встроенный идентификатор устройства, который состоит из двух частей, разделенных двоеточием). Первая часть — это производитель (идентификатор поставщика), а вторая часть — это устройство (идентификатор продукта). Например, 8087 — это идентификатор производителя Intel.

Если у вас есть несколько внешних USB-портов, вы можете поместить устройство в порт и запустить lsusb по запросу в терминале. Из вывода можно определить, какой порт к какой шине принадлежит. Сделав это, вы сможете определить, какой порт соответствует стандарту USB и какой скорости.

Чтобы просмотреть USB-устройства в виде дерева, вы можете использовать команду «lsusb -t», как показано на рис. 4, которая является выходными данными системы на рис. 3.

Итак, давайте снова вернемся к рисунку 2. Здесь мы видим семь корневых концентраторов, перечисленных как шины с 1 по 7. Чтобы иметь возможность отключить шину, нам нужно иметь для нее номер, который составляется как следует:

Домен:Шина:Слот.Функция
0000:00:00.0

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

lspci | grep USB

ПРИМЕЧАНИЕ. Команда чувствительна к регистру, особенно часть «USB».

Команда grep ищет строки, в которых есть слово USB. Система, показанная на рис. 2, выдаст результат, показанный на рис. 5.

На рис. 5 показаны семь корневых концентраторов с адресами. Отсутствует только доменная часть: 0000. Итак, теперь у нас есть следующие адреса с типом USB:

00:12.0 OHCI – USB 1.1
00:12.2 EHCI – USB 2.0
00:13.0 OHCI – USB 1.1
00:13:2 EHCI – USB 2.0
00:14.5 OHCI — USB 1.1
00:16.0 OHCI — USB 1.1
00:16.2 EHCI — USB 2.0

Есть небольшая проблема. Мы не знаем, какой адрес для какой шины. Если вы провели какое-то тестирование с помощью команды «lsusb» и переместили устройство с порта на порт, у вас должно быть представление о том, какие порты предназначены для какой шины.

Если порт перестает работать и вы хотите отключить этот конкретный корневой концентратор, вам нужно знать, какой порт какой. Если концентратор выходит из строя, вы можете использовать «lsusb -t», чтобы проверить, включен ли он. Например, если ваша USB-мышь перестала работать, и вы знаете, что это шина 5, запустите «lsusb -t», чтобы определить, присутствует ли шина 5 в списке. Если шина 5 не отображается в выходных данных, значит, шина 5 вышла из строя.

Чтобы включить/отключить корневой концентратор, вам нужно знать адрес. Откройте терминал и войдите в систему как root. Войдя в систему как root, вы можете использовать следующую команду, чтобы сопоставить Busevice с адресом:

lsusb -v -s шина:устройство | grep iSerial

Например, если бы мне нужен был адрес корневого концентратора на шине 1, я бы ввел следующую команду:

lsusb -v -s 1:1 | grep iSerial

На рис. 6 показаны результаты, согласно которым корневой концентратор, всегда являющийся устройством 1, на шине 1 находится по адресу 0000:00:12.2.

Одна и та же опция должна быть запущена для всех корневых концентраторов на всех шинах. Моя система выдает следующее:

00:12.0 – Шина 4
00:12.2 – Шина 1
00:13.0 – Шина 5
00:13.2 – Шина 2
00:14.5 – Автобус 6
00:16.0 – Автобус 7
00:16.2 – Автобус 3

Предположим, перестала работать моя мышь, которая подключена к шине 5. Я запускаю команду lsusb и вижу, что шина 5 отсутствует, как показано на рис. 7.

Мне нужно будет выполнить команду, чтобы повторно активировать шину 5. Я уже определил, что адрес шины 5 — 0000:00:13.2, а из команды «lsusb -t» драйвер — «ohci_hcd». Команда выглядит следующим образом:

echo -n "0000:00:13.0" | тройник /sys/bus/pci/drivers/ohci_hcd/bind

Адрес — это адрес устройства. «ohci_hcd» — это команда «lsusb -t». В конце инструкции можно использовать два термина:

  • bind — включить корневой концентратор
  • отвязать — отключить корневой концентратор

echo -n "0000:00:13.0" | тройник /sys/bus/pci/drivers/ohci_hcd/unbind

ПРИМЕЧАНИЕ. Команды можно выполнять в терминале от имени пользователя root.

Будьте осторожны при отключении определенной шины. Если вы случайно отключили клавиатуру или мышь, переместите устройство на другой USB-порт.

Чтобы включить корневой концентратор шины 1, я бы использовал следующую команду:

echo -n "0000:00:12.2" | тройник /sys/bus/pci/drivers/ehci-pci/unbind

ПРИМЕЧАНИЕ: следите за тем, чтобы порт USB 1.1 — это ohci_hcd, а устройства USB 2.0 — ehci-pci.

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

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

Я заметил интересную вещь: если на шине есть действительно проблемное устройство (например, устройство, которое не может быть пронумеровано), этот скрипт не возвращается. Вероятно, он застревает на одной из операций записи для «привязки» (не проверял это полностью).

Используйте на свой страх и риск. Вы root, вы должны знать, что делаете (или играть в азартные игры, как я). Далее следует сценарий.

Если это не работает для вас, проверьте комментарии ниже. Имена файлов /sys немного различаются в разных дистрибутивах.

Несколько слов о том, как работает этот сценарий, поэтому он выглядит так: USB-контроллеры — это устройства PCI/PCIe/поддельные PCI. Таким образом, сценарий переходит в каталог /sys, связанный с драйвером устройств PCI, и отвязывает их от устройства, а затем привязывает обратно. Так что это все равно, что сказать: нет, это устройство не принадлежит водителю, а потом сказать, что оно принадлежит. И на последнем этапе драйвер инициализирует устройство, которое и выполняет работу. Добрый день.

Имена файлов, такие как 0000:00:14.0, которые появляются в /sys/bus/pci/drivers/xhci_hcd/, являются адресами шины PCI контроллеров USB, которые обрабатываются драйвером xhci_hcd. Они исчезнут из каталога после записи «unbind» и вернутся после записи «bind». Имена можно найти в /sys/bus/pci/devices/. Используйте «lspci», чтобы узнать, какое устройство является каким.

Приведенный выше сценарий на самом деле является более новой версией сценария, которую я обновил в июне 2014 года после обновления ядра до версии 3.12. Более старая, к которой относятся некоторые комментарии, такова:

Проблема со старым скриптом заключается в том, что подкаталог EHCI не отображается в моей системе, потому что xHCI является универсальным для всех версий USB, поэтому, когда порт USB поддерживает 3.0, он управляется только драйвером xhci_hcd. . Новый скрипт улавливает все возможности. Надеюсь.

Комментарии читателей

Здравствуйте, вчера я попробовал ваш скрипт, и он отлично сработал. Затем я обновился до Ubuntu 13.04, и теперь я получаю сообщение об ошибке ehci_hcd. У вас есть идеи, почему?

Понятия не имею. Я буду рад, если вы узнаете и опубликуете еще один комментарий о том, как вы решили эту проблему…

sudo ./reset_usb
./reset_usb: строка 17: эхо: ошибка записи: нет такого устройства
./reset_usb: строка 18: эхо: ошибка записи: нет такого устройства
. /reset_usb: строка 21: cd: /sys/bus/pci/drivers/ehci_hcd: Нет такого файла или каталога
Странная ошибка. Не удалось изменить каталог на /sys/bus/pci/drivers/ehci_hcd

Что бы это ни стоило. VMware почему-то любит убивать мой USB.

Хммм… Почему вы использовали старую версию?

Но да, у VMware есть способ воровать USB-устройства у меня под носом, но я не знал, что это также устранило их. :)

199, 12

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

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

Если нет, то знает ли кто-нибудь о какой-либо другой душе, которую я мог бы попробовать? Я видел, что есть команда под названием "udevadm", и с ее помощью вы должны
управлять udev и устройствами, я полагаю. Но я не уверен, поможет ли эта команда моему делу.

Код C в конце поста, по-видимому, "отключает" этот USB-порт, но не переустанавливает устройство.

*USB-модем — это устройство с маркировкой «Conexant Systems (Rockwell), Inc.».

Если я запускаю lsusb перед выполнением программы C, я вижу:

Как видите, на этот раз модем отсутствует. Если я просматриваю /var/log/messages, когда физически отключаю модем ПОСЛЕ того, как я выполняю программу C, я не получаю
вообще никакого вывода, так что кажется, что ядро ​​​​не знает, что там, так как обычно я получаю вывод при отключении ЛЮБОГО usb-устройства.

Но это /var/log/messages во время выполнения программы C:

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

Вот код C:

Если у кого-то есть ЛЮБЫЕ мысли или предложения, поделитесь ими. Не совсем уверен, что еще я могу попробовать здесь.

Заранее спасибо,
Мэтт

хиксd8

2 327 710

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

Во-первых, что это за операционная система.

У вас точно есть правильный драйвер Conexant для этой операционной системы?

Модем — это устройство с последовательным портом, но в данном случае последовательный порт является виртуальным внутри USB-драйвера на хосте.

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

Итак, у вас есть подходящий USB-драйвер для вашей операционной системы?

Настроен ли локальный модем для правильного сообщения о потере несущей (сигнал DCD)? См. руководство по этому модему.

199, 12

Привет, спасибо за ответ.

ОС: OpenSuSE 13.1 (бутылка)
ПК: процессор CuBox-i arm

Да, хотелось бы. Но в некоторых случаях кажется, что модем зависает, перестает принимать AT-команды и в определенное время
перестает отвечать на запросы. В большинстве случаев он корректно сбрасывается при неожиданном зависании, но не всегда. Было несколько раз, когда я случайным образом
вешала трубку
на другом конце (*во время тестирования), просто чтобы посмотреть, что происходит, и модем полностью блокировался, и это был единственный способ вернуть его обратно. либо перезагрузить компьютер, либо
отключить и снова подключить модем.

Это второй USB-модем, который я пробовал использовать. Первым модемом был USB-модем Zoom модели 3095. Этот модем работал НАМНОГО лучше с точки зрения того, что никогда не
блокировался, но была проблема с тем, что внешний идентификатор вызывающего абонента НЕ работал, когда CID поступал от TelCO. Я почти уверен, что дело в mgetty, так как
внешний CID работал в Putty (*для linux и Windows). Но поскольку ПК будет исключать вызовы на основе CID, эту часть нельзя было исключить, поэтому мы попробовали
TRENDnet TFM-561U. На этом модеме CID отлично работал с mgetty, поэтому мы решили использовать его, так как CID имел первостепенное значение.

Странно то, что оба этих модема выглядят ТОЧНО одинаково, кроме физического цвета модемов, они одинаковы. Даже если вы просматриваете
/var/log/messages при подключении каждого модема, оба сообщают один и тот же серийный номер и производителя. Если вы посмотрите на вывод ниже,
вы увидите одно и то же при подключении каждого модема. Так что можно подумать, что они будут работать примерно одинаково.

Вывод из "/var/log/messages", драйвер "cdc_acm":

Я не уверен, является ли cdc_acm правильным драйвером или нет, поэтому на прошлой неделе я попытался использовать драйвер, поставляемый с модемом Zoom. Модем TRENDnet
не имел на диске драйвера для Linux, только для Windows. Итак, я попытался скомпилировать драйвер Linux, который был на диске модема Zoom, но не смог
сделать это, так как у меня нет исходного кода ядра на этой машине для компиляции драйверов/модулей ядра. И я никак не мог понять, как эту часть
выполнить.

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

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

Вывод из "/var/log/mgetty.ttyACM0":

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

Читайте также: