Opened 15 months ago

Closed 12 days ago

#704 closed баг (fixed)

Странное поведение резервирования потоков E1 платой SW-01

Reported by: alx Owned by: alx
Priority: средний Milestone: 1 очередь
Component: ПЛИС (sw) Keywords:
Cc:

Description

В плате SW-01 я столкнулся со странным поведением функции резервирования потоков E1. В результате экспериментов обнаружено сразу много странностей. Опишу эксперименты по порядку.

Исходное состояние: в ПЛИС загружена прошивка версии 12, потокам 5E1 и 6E1 настройки СУВ установлены в значения "выкл" и "abcd".

  1. Поток 6E1 настраивается резервным для потока 5E1, в строке "Активировать при" отмечен только чекбокс "СЦС", также отмечен чекбокс "Возвращаться на основной поток", параметр "Таймаут возврата на основной" установлен в значение 50 секунд.

Результаты эксперимента:

  • бит 0 регистра 0x124 ПЛИС равен единице, что означает аварию СЦС основного потока, хотя такой аварии нет - в регистре 0x103 ПЛИС бит 4 равен нулю. Ожидалось, что бит 0 регистра 0x124 будет возвращать то же значение, что и бит 4 регистра 0x103, так как основным потоком назначен 5E1.
  • бит 4 регистра 0x124 ПЛИС равен единице, что означает аварию СЦС резервного потока, хотя такой аварии нет - в регистре 0x103 ПЛИС бит 5 равен нулю. Ожидалось, что бит 4 регистра 0x124 будет возвращать то же значение, что и бит 5 регистра 0x103, так как резервным потоком назначен 6E1.
  • бит 4 регистра 0x124 ПЛИС периодически меняет свое значение с 0 на единицу и обратно, что означает переходы с основного потока на резервный и обратно (активацию/деактивацию резерного потока). Ожидалось, что резервный поток никогда не будет активирован, так как, во-первых, у потока 5E1 нет аварии СЦС, во-вторых, если учесть, что схема резервирования почему-то ложно считает, что авария есть, резервный поток все равно не должен был быть активирован, так как он точно так же имеет (ложную) аварию, а, согласно РЭ блока MC04-DSL-3U, если резервный поток в аварии, он не активируется.
  • время активности резервного потока составляло единицы секунд (обычно 2-3 секунды). Ожидалось, что время активности резервного потока не будет меньше 50 секунд, так как параметр "Таймаут возврата на основной" установлен в значение 50 секунд.

Вот результат чтения регистров ПЛИС 0x103 и 0x124 (чтение выполнялось с интервалами около 1 секунды):

root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 00
0x0000: 00 00 00 00 11
  1. Настройка СУВ потока 5E1 установлена в значение "КИ16". В результате у потока 5E1 появилась авария СЦС - бит 4 регистра 0x103 стал единицей (что правильно), однако в работе резервирования ничего не изменилось. Вот результат чтения регистров ПЛИС 0x103 и 0x124 (чтение также выполнялось с интервалами около 1 секунды):
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 19
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11
root@sw01:~# spictl 01 03 00 00 00; spictl 01 24 00 00 00
0x0000: 00 00 00 a0 10
0x0000: 00 00 00 00 11

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

Конфигурация резервирования была прочитана из ПЛИС, и она соответствует ожидаемой:

root@sw01:~# spictl 1 20 0 0 0
0x0000: 00 00 00 04 00
root@sw01:~# spictl 1 21 0 0 0
0x0000: 00 00 00 05 00
root@sw01:~# spictl 1 22 0 0 0
0x0000: 00 00 00 01 00
root@sw01:~# spictl 1 23 0 0 0
0x0000: 00 00 00 32 00
  1. Режим СУВ 5E1 вернул в значение "выкл", в ПЛИС "на ходу" загрузил прошивку версии 13.

Результат: первое время (около 30 секунд, специально не измерял) видел в веб-интерфейсе, как резервный тракт несколько раз поменял состояние (активировался/деактивировался), после чего "застрял" в активированном состоянии.

  1. В ПЛИС "на ходу" загрузил прошивку версии 12.

Результат тот же: сначала резервный тракт менял состояние, после чего "застрял" в активированном состоянии.

Судя по описанным наблюдениям, различий в поведении прошивок версий 12 и 13 нет. Отличия результатов экспериментов 3 и 4 от эксперимента 1 вероятно как-то связаны с тем, что прошивка ПЛИС менялась "на ходу". Я попробую воспроизвести первоначальное поведение и по результатам дополню тикет.

Предлагаю попробовать выяснить причины неправильного поведения ПЛИС и устранить их.

Change History (8)

in reply to:  description comment:1 by alx, 15 months ago

Replying to alx:

Я попробую воспроизвести первоначальное поведение и по результатам дополню тикет.

Дополняю.

ПЛИС версии 12, резервный поток "залип" в активном состоянии. Отключил резервирование потока 6E1, а затем снова включил. В результате эксперимент 1 сразу воспроизвелся - поток переключался туда-сюда и не "залипал" в одном состоянии.

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

Last edited 15 months ago by alx (previous) (diff)

comment:2 by alx, 2 weeks ago

Так как разработчиком ПЛИС назначен я, соответствующие тикеты забираю себе.

comment:3 by alx, 2 weeks ago

Owner: changed from anatoly to alx

in reply to:  description comment:4 by alx, 12 days ago

Replying to alx:

  • бит 0 регистра 0x124 ПЛИС равен единице, что означает аварию СЦС основного потока, хотя такой аварии нет - в регистре 0x103 ПЛИС бит 4 равен нулю.

Эта загадка разгадана. В результате анализа исходного кода обнаружена ошибка в ПЛИС: оказалось, что отключение CAS влияет исключительно на индикацию аварии/извещения и только в регистрах 0x103, 0x104, 0x110 и 0x111. На работу внутренней логики и на индикацию аварий в регистрах 0x124, 0x12c, 0x134 и 0x13c это отключение почему-то никоим образом не влияет.

comment:5 by alx, 12 days ago

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

in reply to:  description comment:6 by alx, 12 days ago

Replying to alx:

  • бит 4 регистра 0x124 ПЛИС периодически меняет свое значение с 0 на единицу

Это объясняется тем, что во время эксперимента в КИ16 резервного канала плата VE-01 передавала сигнализацию ISDN PRI. В передаваемых там сигнальных пакетах могла образоваться комбинация 0000 на месте сверхциклового синхросигнала. При появлении такой комбинации ПЛИС считает, что вошла в сверхцикловый синхронизм и снимает аварию СЦС. Как результат, возникает условие перехода на резервный поток. Таким образом, в переходе на резерв ошибок нет.

in reply to:  description comment:7 by alx, 12 days ago

Replying to alx:

  • время активности резервного потока составляло единицы секунд (обычно 2-3 секунды). Ожидалось, что время активности резервного потока не будет меньше 50 секунд, так как параметр "Таймаут возврата на основной" установлен в значение 50 секунд.

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

Изначально такое поведение (нижняя часть приведенной диаграммы) мне показалось неправильным, так как я ожидал, что любой возврат на основной поток должен выполняться по таймауту. Однако сейчас я перечитал РЭ и обнаружил, что так и должно быть:

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

Таким образом, формально, все работает правильно, неверными были мои ожидания.

Last edited 12 days ago by alx (previous) (diff)

comment:8 by alx, 12 days ago

Resolution: fixed
Status: assignedclosed

In 2569/sw:

Испарвлена ошибка в ПЛИС: при отключенных СУВ потока
все равно могла формироваться и использоваться (например
функцией резервирования потоков E1) авария СЦС. Это приводило
к ложным переходам на резервный поток и ложному возврату с него.
Closes #704. See #698.

Note: See TracTickets for help on using tickets.