Добрый день!
Столкнулись с неприятной ситуацией.
Контроллер WB7 управляет тепловым пунктом на критически важном объекте.
Внезапно в 5 утра присоединенный модуль WBIO-DI-DR16 (по счету второй в линейке из семи) перестал показывать реальные статусы сухих контактов. Часть входов должны быть замкнуты, но все входа отображаются как false.
Сам контроллер не перезагружался, видим uptime 6d.
После принудительной перезагрузки контроллера из вэб-интерфейса ситуация с отображением наладилась.
Такое происходит второй раз за неделю.
Помогите разобраться, в чем причина такого поведения модуля/контроллера.
Логи для диагностики прилагаю.
Приветствую!
Меня сильно смущает ругательство “mv64xxx” в логах; поэтому:
Нет ли каких-либо сторонних устройств на шине боковых модулей?
Хочется результат dtc -I fs /proc/device-tree > dts.txt
И lsmod > lsmod.txt
Какой релиз на контроллере? (wb-release)
Работают ли модули, идущие после неработающего?
Бывало ли такое раньше, или началось недавно?
Предварительно подозреваю какие-то аппаратные проблемы, поэтому хочется получить от Вас описание инсталляции (а в идеале бы - с фото, если есть возможность).
Предполагаемый костыльный способ лечения (кроме перезагрузки) - это systemctl stop wb-mqtt-gpio; modprobe -r pinctrl_mcp23s08_i2c; modprobe pinctrl_mcp23s08_i2c; systemctl restart wb-mqtt-gpio
P.S. прямо сейчас у нас в работе - детектирование отваливающихся WBIO-модулей (будут гореть красным в webui) => было бы здорово попробовать, работает ли в Вашем случае (устанавливать, начиная с wb-2310): тык
Всё на вид плотно сидит (да и было бы странно, если бы при плохом контакте помогала перезагрузка).
Сторонних устройств нет на шине. Отдельно сидят 2 MAI-6 на RS485.
dtc -I fs /proc/device-tree > dts.txt -вывод прилагаю
lsmod > lsmod.txt -ничего не происходит
Wirenboard release wb-2304 (as stable), target wb7/bullseye
Модули после неработающего - вроде работали, по крайней мере показывали что-то похожее на правду. Но есть подозрение, что вместе со вторым не работали до ребута еще 1 и 3, на скриншотах в первом посте видно, что там тоже появились true, которых не было.
Шина:
1=WBIO-DI-DR8
2=WBIO-DI-DR16
3=WBIO-DI-WD14
4=WBIO-DO-R1G-16
5=WBIO-DO-R10A-8
6=WBIO-DO-R10A-8
7=WBIO-DO-R10A-8
Была похожая ситуация 1 раз неделю назад, но персонал по месту сразу перезагрузил не вникая. Контроллер в работе более полугода на объекте.
Свежего фото нет, прилагаю что, что осталось с наладки.
Добрый день!
Проблема повторяется.
Первые три модуля на шине - в вэбе все статусы бледные - неактивные. Фактическое состояние входов не отображают.
1=WBIO-DI-DR8
2=WBIO-DI-DR16
3=WBIO-DI-WD14
Последующие модули - вроде норм.
Если ребутнём, скорей всего связь восстановится.
Помогите решить проблему.
Можем дать удал.доступ.
Логи для диагностики прилагаю.
Feb 13 02:55:34 wirenboard-AJNXWCAN kernel: i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
Feb 13 02:55:36 wirenboard-AJNXWCAN kernel: i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
Feb 13 02:55:38 wirenboard-AJNXWCAN kernel: i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
Feb 13 02:55:40 wirenboard-AJNXWCAN kernel: i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
Предполагаю что один из модулей (сам чип!) подвис, притянув шину к земле.
Воспроизвожу.
Обновите пожалуйста ПО на контроллере, в новых релизах есть анализ доступности WBIO модулей.
Модулей шесть. Действенный способ диагностики - отключать (отодвигать) по одному. Как только будет отключен зависший (предположительно) - оставшиеся заработают. Ну и в dmesg перестанет вываливаться ошибки блокировки шины.
Сейчас попробуем выявить отключением.
Только возникают 2 вопроса, почему не вся шина просаживается, а только “середина”, т.е. при этом конец шлейфа на связи. И почему при такой ситуации (если проблема в модуле) помогает мягкая перезагрузка контроллера из веб-интерфейса?
По месту выявить зависший модуль не удалось, к сожалению.
Ввиду важности объекта принято решение заменить всю линейку модулей на аналоги WB, но по RS485, а эксперименты с этими модулями проводить уже отдельно.
