OS7400 DTMF-приемники

[LionB]

Watchdog - ситуация, при которой приостановились все операции процессора (какой-то глюк и он завис) и в нем нет никакой активности.
Опция позволяет уходить по этой ситуации в перезагруз автоматически

[Alexandre]

"Никогда такого не было - и вот опять!"
Короче, на внутренних аналоговых портах снова пропадает тоновый набор, но железо уже совсем другое:
OS7400, 3 корзины, MP40 V4.98, LP40 2.04,
TEPRI2 V4.28, OAS V2.10, CNF24 V1.02, SVMi-20i V6.09,
8TRK2 – 1 шт, 16DLI2 - 2 шт, 16SLI2 – 24 шт.
В LP40 CRM'ы в Loc 1. Оба DSP настроены на режим DTMFR.
Проблема появилась после перехода с версии 4.75 на 4.92. На 4.98 тоже самое.
Периодически, может раз в день, какой-то внутренний аналоговый абонент теряет способность набирать в тоновом режиме, причем похоже и остальные абоненты на этой же плате. Абоненты могут быть из первой и из второй корзины, на третьей просто пока никто не подключен.
Неисправность или устраняется сама по себе или перезагрузкой платы. В момент появления неисправности смотрим 6.2.6 System Resourse, а там – заняты всего 2-3 приемника, а 82-81 соответственно свободны, т.е. никакой перегрузки нет. Есть сохраненные SysLog'и в которых зафиксированы эти случаи. Правда, не все термины лога могу правильно интерпретировать. Хорошо бы инструкцию на эту тему получить. Хотя, для установщиков может никогда и не дадут.
Кроме того, запускал mptTool с трассировкой событий Call, Evnt и CDIT. Там тоже есть сбойные ситуации. Но что делать дальше - непонятно.
Надо ли предоставить трассировку с LP40 по методике описанной выше или для этого железа все делается по-другому. Может уже достаточно того, что теперь есть mptTool? Жду дальнейших инструкций. Ситуация потихоньку накаляется.

[LionB]

Выложи настройки и те самые логи с ошибками.

[Alexandre]

Вот фрагмент Syslog'а и трассировки MptTool'ом в момент когда внутренний номер 190 пытается что-то набрать, но станция ему после первой же цифры дает опять тон готовности и он кладет трубку:

63918 11/17 11:06:32
64089[203:190 ]<LPM d_idle hook_off 013b
64089[203:190 ]>LPM d_idle slc_msg 0c01
64089[203:190 ]>TSW_TONE Rx(0000)
64189[203:190 ]<tmr d_dial first_dgt 13ff
64189[203:190 ]>TSW_OFF Rx(ffff)
64189[203:190 ]>TSW_TONE Rx(0005)
64233[203:190 ]<LPM d_error hook_on 023b
64233[203:190 ]>TSW_OFF Rx(ffff)
64233[203:190 ]<call d_rls state 1a09
64233[203:190 ]<call d_rls get_rq_r 7801
64233[203:190 ]>TSW_OFF Rx(ffff)
64233[203:190 ]>LPM d_idle slc_msg 0c01

Трассировка mptTool:
[MP_DEBUG] >>>>>>>>>> CUR TIME >>>>>>>>>>>> 11:06:47 11/17
04964089[203:190 ]<LPM d_idle hook_off 013B0090
04964089[203:190 ]>LPM d_idle dsp_chip 01000002 00FF0023
04964089[203:190 ]>LPM d_idle slc_msg 0C010000 20202020 20202020 20202020
04964089[203:190 ]>LPM d_idle tsw_gain 39030000 FF000000
[MP_DEBUG] >>>>>>>>>> CUR TIME >>>>>>>>>>>> 11:06:52 11/17
[MP_DEBUG] >>>>>>>>>> CUR TIME >>>>>>>>>>>> 11:06:57 11/17
04964233[203:190 ]<LPM d_error hook_on 023B0000
04964233[203:190 ]>LPM d_error tsw_gain 3904FFFF FF000000
04964233[203:190 ]<call d_rls state 1A090203 190F0203 190F010B FFFFFFFF
04964233[203:190 ]<call d_rls get_rq_r 78010203 190F0203 190F0109 FFFFFFFF
04964233[203:190 ]>LPM d_rls tsw_gain 3904FFFF FF000000
04964233[203:190 ]>LPM d_idle slc_msg 0C010000 20202020 20202020 20202020

Конфиг станции и полные логи отправляю непосредственно Льву.

[Alexandre]

Проинформирую о состоянии дел по проблеме с приемниками DTMF.
По-прежнему практически каждый день внутренние аналоговые абоненты жалуются на невозможность набирать в тоне. Причем, проблема затрагивает только какую-то одну плату 16SLI2 из любой корзины. Это может длиться минут 10-15 и потом или сама исчезает или инженер, обслуживающий станцию, делает через DM Reset этой платы и все восстанавливается.
А пару дней назад станция и вовсе зависла - на аналоговых портах есть напряжение, но нет гудка, а на системниках - номер версии прошивки. Сбросили через DM - процессор еще работал.
Разработчику отправлены все необходимые логи и трассировки регистрирующие эти ситуации, а также всякие уточнения по интересующим его вопросам. Я не стал все это выкладывать на форум, так как, думаю, в этой ситуации мало кто сможет кроме самого разработчика разобраться.
Есть одно предположение, что все 3 LP40 прошились каким-то битым файлом.
Сегодня по просьбе разработчика сделал Downgrade LP40 с V2.04 на V2.02. При этом, столкнулся с тем, что в обратную сторону LP40 шьется где-то 28 минут. После того как прошли привычные 15 минут, а огоньки все бегают по кругу, я уже было начал разматывать консольный шнурок SIO для аварийного восстановления прошивки и чуть было не нажал Reset.
Короче, наблюдаем даст ли это какой-то эффект.

[Alexandre]

Не помогло
Видно будем откатываться на исходную версию процессора V4.75 на которой этой проблемы не было.
Версия с битым файлом прошивки LP40 V2.04 отпала, проверял побитно с файлом полученным от самого LionB.