Opened 3 years ago

Closed 3 years ago

#559 closed баг (готово)

Плата на месте 10 теряет связь с платой на месте 9

Reported by: san Owned by: alx
Priority: высокий Milestone: 1 очередь
Component: swd Keywords:
Cc: mixyil1.1

Description

Миша в ходе настройки одного из объектов пользователя обнаружил странное поведение основной и резервной платы sw-01

После включения блока, через минуту, плата SW-01 на месте 10 сообщает, что плата на месте 9 неактивна и берёт управление на себя.
При этом предпосылок для отсутствия связи нет, spi у обеих плат работает, после активации платы 9 вручную, платы работают штатно, ошибок в spi нет.
Проблема повторно воспроизвелась при нескольких включениях блока.

Логи плат положил в xchange\alx\Test_and_bugs\SW-01\
Проблему можно увидеть при последнем включении
10.90.48.67.messages - плата на месте 10
10.90.48.68.messages - плата на месте 9

Change History (10)

comment:1 by alx, 3 years ago

Насколько я вижу, в одном из блоков неверное время, из-за чего разница во времени между блоками составляет 6 секунд. Далее я буду указывать время по часам резервной платы (слот 10).

Плата в слоте 10 взяла управление блоком в 09:50:32:

Dec 29 09:50:32 sw01 daemon.err swd[254]: switching to MASTER mode due to master inactivity

Непосредственно перед этим в логе имеется такая запись:

Dec 29 09:49:32 sw01 daemon.info swd[254]: slot 10: switching to CRC16 mode

Это означает, что активная плата SW-01 отправила резервной плате запрос переменных .1.0, .2.0, .3.0 в режиме CRC16, что и вызвало такую смену режима. Однако в логе активной платы нет записи о том, что обнаружена плата в слоте 10. Разница между временем этих событий составляет 60 секунд.

Я предполагаю, что по каким-то причинам в процессе передачи ответа на запрос от резервной платы к основной плате сообщение было искажено и, как результат, отброшено (проигнорировано) принимающей платой. Последующие запросы активной платой передавались уже в режиме XOR8, но, так как резервная плата перешла в режим CRC16, эти сообщения она игнорировала. Из режима CRC16 плата должна была перейти обратно в режим XOR8 по таймауту - если в течение 60 секунд ей не было принято ни одного валидного сообщения от активной платы (этот переход не сопровождается записью в логе). Однако, так как в данном случае речь идет о резервной плате SW-01, по такому же критерию (отсутствие запросов от активной платы) она принимает на себя управление блоком. По "неудачному" стечению обстоятельств таймаут перехода в активный режим также составляет 60 секунд.

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

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

comment:2 by alx, 3 years ago

Component: swswd

comment:3 by san, 3 years ago

В таком случае остаётся вопрос: как же так "удачно" получается в этом блоке воспроизводить эту ситуацию каждое включение (как минимум три последних включения) ?

in reply to:  3 comment:4 by alx, 3 years ago

Replying to san:

как же так "удачно" получается в этом блоке воспроизводить эту ситуацию каждое включение (как минимум три последних включения) ?

У меня нет ответа на этот вопрос.

comment:5 by alx, 3 years ago

In 2137/sw:

Таймаут возврата транспортов по каналу управления платами SPI из режимов CRC16 и CRC32
в режим XOR8 уменьшен с 60 до 40 секунд.
Таймаут активации резервной платы SW-01 увеличен с 60 до 70 секунд.
Предположительно это решит проблему ложной активации резервной платы, вызванной рассинхронизацией
режимов транспорта между основной и резервной платами SW-01. See #559.

comment:6 by alx, 3 years ago

Саша, есть ли возможность провести проверку, что с r2137 проблема перестала воспроизводиться?

Last edited 3 years ago by alx (previous) (diff)

comment:7 by alx, 3 years ago

Тот же вопрос Мише. :)

comment:8 by san, 3 years ago

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

in reply to:  6 comment:9 by mixyil1.1, 3 years ago

Replying to alx:

Саша, есть ли возможность провести проверку, что с r2137 проблема перестала воспроизводиться?

Этот вопрос необходимо согласовать с Андрем Хомяковым. Необходимо получить удаленный доступ к объекту и разрешение производить манипуляции с блоком.

comment:10 by alx, 3 years ago

Resolution: готово
Status: newclosed

В виду отсутствия возможности подтвердить решение проблемы буду считать, что она решена.

Note: See TracTickets for help on using tickets.