LINUX.ORG.RU
решено ФорумAdmin

последовательные порты и модемы на шине USB в новом дебианчике

 , ,


0

1

Имеется система Debian GNU/Linux 6.0 (Squeeze) i686 на основе DELL PowerEdge 1400 с двумя COM-портами. В /dev/ttyS0 вставлен термометр на основе DS18S20+, в /dev/ttyS1 — ИБП APC Smart-UPS 620. На этом шасси есть также есть два порта USB. В один из них воткнут Megafon Huawei E173.

Работает всё шоколадно: температура мониторится, модем отсылает SMS, для чего стоят пакеты usb-modeswitch и gammu, базовая часть работает из коробки, нижний уровень обслуживают пакеты, установленные из штатных репозиториев. Модем видится автоматически, ничего настраивалось: при втыкании или при перезагрузке хоста его файлики устройств появляются в системе автоматически. С термометром также проблем нет.

Была попытка перенести эту систему мониторинга обновив железо сервера на HP Core2Duo / 3GB RAM. И обновив ОС на Debian GNU/Linux 8.0 (Jessie) amd64. В новом железе штатный COM-порт — один. второй распаян на материнке на внутренний нестандартный разъем, и искать косичку к нему нецелесообразно, зато USB-портов вдоволь — 6 штук сзади, два — спереди. Поэтому в систему был добавлен COM-порт в виде переходника USB-COM. ИБП был воткнут в /dev/ttyS0, с ним проблем нет.

Остальные два компонента работы с последовательными устройствами — старые модем и термометр, были воткнуты в USB, последний — через переходник USB-COM. И сразу начались проблемы:

Переходник USB-COM видится сразу, как /dev/ttyUSB0, но по мере игр с модемом и перезагрузкой, его нумер меняется; при дальнейших играх, часть функциональности пропадает на лету: утилита из пакета digitemp выдает только ID, но значение показания температуры в процессе игр сначала начала выдавать через раз, а потом совсем перестала выдавать, но ID термометра при этом выдает ок, причем, насколько помню, передергивание по USB не помогает. Сначала думал, что это из-за того, что обращаюсь к устройству «более унифицированным» способом, т.е. указывая /dev/serial/by-id/... (ведь это надо из-за того, что в мистеме на шине USB два последовательных устройства, которые могут менять в общем случае свои нумера), но играясь дальше, заметил, что такой эффект достигается и при указании файла устройства напрямую, т.е. /dev/ttyUSB?, где ? — нумер, соответствующий переходнику USB-COM. Также, при указании длинного /dev/serial/by-id/... в конфигурационном файле считывателя температуры, из того же пакета digitemp, консольная утилита опроса термометра слетает с ошибкой (не знаю, сегфолт или нет, выводит какой-то длинный шестнадцатиричный код, на конфиг не ругается).

Модем видится только с шаманскими танцами, с бубном конечно. Приходится править конфиг пакета usb-modeswitch, вручную указывая параметры DefaultVendor= 0x12d1 и DefaultProduct= 0x1446 . Мало того, при этом, при втыкании в хост или при перезагрузке хоста, модем автоматически не подхватывается, и приходится вручную запускать usb_modeswitch для появления файлов его устройств в файловой системе. Поскольку в восьмом дебианчике система инициализации на основе systemd, я еще не предполагаю, как можно запустить эту команду правильно, чтобы при старте модем инициализировался ОК. Добавление в планировщик с помощью crontab -e для пользователя root для «времени» @reboot было бы ну очень большим костылем.

Хорошо хоть после этого пакет gammu нормально отсылает SMS-сообщения, т.е. нет аналогичных проблем, как у термометра, что что-то из того, что надо, не работает.

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

С ходу, в гугле, ни на ЛОРе не удалось найти ни похожих проблем, ни, тем более, их решения.

Вопрос: как сделать так, чтобы с новым железом и ОС сервера было также хорошо, как и в старом? :-)

★★★★★

Есть ли проблемы с термометром, если отключить usb_modeswitch? Возможно, эта утилита не понимает, что ttyUSBx от термометра это не модем и пытается сменить его режим, вызывая глюки в работе с ним, и при этом не находя настоящий модем.

Если эта теория верна, то надо будет как-то захардкодить какой порт надо использовать usb_modeswitch.

У меня была похожая проблема с самопальным USB CDC на микроконтроллере. После втыкания в ноутбук порядка 30-секунд я не мог открыть COM-порт - «Device or resource busy». lsof ничего не дал, то ли какой-то глюк, то ли я что-то напутал. Так и страдал, пока однажды не допустил ошибку в прошивке и МК не начал выдавать через USB CDC данные на максимально возможной скорости. В итоге вентилятор ноутбука загудел сильнее обычного и это не прекратилось после отключения девайса. Посмотрел в htop - процесс ModemManager (компонент NetworkManager для поддержки 3G-модемов) отжирал 100% одного ядра, судя по всему он не выдержал такого потока данных и завис. Я решил проблему отключив сервис ModemManager (я всё равно уже больше года не имел дела с 3G модемами, а 4G представляются как USB Ethernet и с ними проблем вообще нет) и больше не сталкивался с необъяснимой занятостью USB CDC. Насколько я понимаю, у тебя usb_modeswitch в автоматическом режиме ищёт USB-модемы и что-то с ними делает. Он может нечаянно попытаться что-то сделать с твоим термодатчиком, а поскольку ни тот, ни другой такого не ожидает появляются различные глюки в работе обоих.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от mky

Посмотрел повнимательней. Новое железо — это HP Compaq dc7700p Convertible Minitower

dc7700pC/E6600/160hnq/1.0R/8k RUSS

Все дырки USB — черные: и спереди, и сзади; синих нет.

Дискретных хост-контроллеров USB, воткнутых в разъемы шины PCI/PCIe, также не наблюдается.

Также есть вот такие данные:

root@sysresccd /root % lspci -nn | grep -i usb
00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 02)
00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 02)
00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 02)
00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 02)
00:1d.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 02)
00:1d.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 02)

Явно, что в системе нет третьей версии USB со стороны хоста.

Infra_HDC ★★★★★ ()
Ответ на: комментарий от KivApple

Поскольку термометр доступен в единственном экземпляре, переставить его не могу: он подключен к старому железу и в активном процессе: Nagios дергает его каждые 5 минут, и нужно останавливать старый сервер, который по ходу дела выполняет еще другие функции. А останов сервера для данной манипуляции необходим в виду того, что COM-порт — не горячего втыкания.

Пакет modemmanager не стоит ни на старом, ни на новом сервере.

Infra_HDC ★★★★★ ()
Ответ на: комментарий от Infra_HDC

COM-порт — не горячего втыкания.

просто соедини земли сначала, чтобы потенциалы уравнять. (или как там это по-научному) ;))
в остальном - шансы спалить исчезающе малы.

aol ★★★★★ ()
Ответ на: комментарий от Infra_HDC

Ну пока можете поразбираться с модемом. С приходом systemd всё стало навороченнее, udevd сейчас не вызывает команду usb_modeswitch, а обращается к сервису usb_modeswitch@.service. И какие-то баги с переключением модема гуглятся, не обязательно вашей модели, гуглятся.

@reboot это костыль, он него надо избавлятся, думаю, что нужно включить логирование всего, что пытается сделать udev. Может это и для термометра поможет.

У вас логи (dmesg) от предыдущей загрузки с подключенным термометром сохранились? Там модуль ds2490 случаем не загужался, или может ещё какие модули грузились и мешали работать digitemp?

Ну и ещё, может вам будет проще заставить работать UPS через usb->rs232 переходник, чем термометр. COM-порт UPS'ов я подключал/отключал на ходу, у них земля com-порта это корпус, а корпус UPS и компа связаны шнуром питания.

mky ★★★★★ ()
Ответ на: комментарий от mky

С модемом играться могу, да, т.к. второй такой же модем у меня есть, сниму с другого неработающего сервера, модель модема такая же. И пока могу подключить его через неуправляемый ИБП, не требующий свободного порта RS232. А насчет перетыкания термометра: так мне легче новый спаять, благо есть опыт. И запас будет на всякий случай.

Infra_HDC ★★★★★ ()
Ответ на: комментарий от mky

Такой вопрос, а если я соберу пакет снапшот usb-modeswitch более новой версии из исходника, это может быть решением, хотя бы теоретически?

Infra_HDC ★★★★★ ()

Дай угадаю: ты поставил ненужноД вместо системы инициализации?

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от mky

Обалдеть! Еще одно доказательство того, что поцтерофилы — совсем съехавшие рептилоиды...

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Infra_HDC

COM-порт — не горячего втыкания

Ты еще скажи, что SATA нельзя на горячую подключать. Нет, что USB нельзя на горячую подключать ☺

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Я уже ненужноД снес и поставил ми-ми-ми убунточку 14.04.2 . Но на ней новая проблема: не собирается xtables-addons, ни через dkms, ни через module-assistant. Поэтому ищу третий путь. Например FreeBSD — там еще нет такого, хотя и там скоро будет. :-)

Infra_HDC ★★★★★ ()
Ответ на: комментарий от Infra_HDC

убунточку

Лучше мастдайку поставил бы...

Если тебе часто что-то компилять надо, так и ставил бы генту. Бубунта — это же полный финиш. Ниже — только 10-я мастдайка.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

xtables-addons вроде бы, не ставятся по-другому. Вообще, не люблю пакеты собирать. От этого глаза краснеют.

Infra_HDC ★★★★★ ()

А это не энергосбережение играет злую шутку? И ещё, чтобы не искать каждый раз где твой переходник на этот раз, поищи его в /dev/serial Я там тоже забирал свою уэсбэшку, иначе попадаешь то на неё, то на модем.

Deleted ()
Последнее исправление: Chelobaka (всего исправлений: 1)

Вернемся к нашим Дебианам.

Включаю протоколирование:

# nano -w /etc/usb_modeswitch.conf
...
EnableLogging=1
...
# systemctl reboot

(Пардон за ребут системы, # service udev restart не дает эффекта) И что я вижу? А вот что:

# cat /var/log/usb_modeswitch.log


USB_ModeSwitch log from Fri Jun  5 20:51:57 2015

Use global config file: /etc/usb_modeswitch.conf


Started via systemd
Raw args from udev: 5-3-5-3:1.0

Bus ID for device not given by udev.
 Trying to determine it from kernel name (5-3-5-3:1.0) ...
Top device directory not found (/sys/bus/usb/devices/5-3-5-3)! Exit.

И это только для пакета usb-modeswitch_2.2.0+repack0-2ubuntu2_amd64.deb, вручную вкоряченного в Debian 8. Родной дебиановский usb-modeswitch не пишет в лог _ничегошеньки_.

При этом в указанном каталоге _примерно_ такое безобразие:

# ls -l /sys/bus/usb/devices | grep 5-3
lrwxrwxrwx 1 root root 0 июн  5 22:39 5-3:1.0 -> ../../../devices/pci0000:00/0000:00:1a.7/usb2/5-3/5-3:1.0
lrwxrwxrwx 1 root root 0 июн  5 22:39 5-3:1.1 -> ../../../devices/pci0000:00/0000:00:1a.7/usb2/5-3/5-3:1.1

Где 5-3 — меняется от ребута к ребуту (может быть 2-3, 5-4, 2-4 и т.п.) и/или от того, в какое гнездо USB втыкаешь.

Что в глаза бросается сразу, так это то, что вместо 5-3:1.0, или как ее там, идет 5-3-5-3.

Где-то на буржуйском форуме писнули, что в файле usb_modeswitch@.service вместо %I вставлять именно эти цифири, но это еще тот костыль, который с учетом их плавучести работать будет до первого ребута или вытыкания втыкания.

Infra_HDC ★★★★★ ()

UP!

Снес (purge) пакетики из родного репозитория и поставил с sid — что там было свеженького на вчера, включил протоколирование, как и в предыдущем сообщении.

root@automon:~/install/from-sid-dont-work# ls -l
итого 212
-rw-r--r-- 1 root root 113434 май 27 10:52 libjim0.76_0.76-1_amd64.deb
-rw-r--r-- 1 root root  54760 май 28 20:14 usb-modeswitch_2.2.1+repack0-1+b1_amd64.deb
-rw-r--r-- 1 root root  41486 апр 14 16:10 usb-modeswitch-data_20150115-1_all.deb

Результат: лог не обновился, пусто.

Infra_HDC ★★★★★ ()

UP2!

Пощупал Ubuntu 15.04 amd64 desktop. Даже не ставя на диск, с лайв-дивиди

Что могу сказать?

1. Модем завелся после sudo apt-get update ; sudo apt-get upgrade: увиделись устройства /dev/ttyUSB[0-2] после втыкания свистка (у десктопа пакет usb-modeswitch стоял из коробки, и потребовалось лишь его обновление или не только его, чтобы модем увидился).

2. Добавил в sources.list секцию universe и успешно собрал xtables-addons-dkms.

Вполне вероятно, все взлетит и на сервере, т.к. пакетная база общая. Буду ориентироваться.

Infra_HDC ★★★★★ ()

UP3! Обновился с 8.0 до 8.1 . Проблема осталась.

Infra_HDC ★★★★★ ()

UP4!

Установка Wheezy 7.8 AMD64 решила проблему.

Тема закрыта.

Infra_HDC ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.