id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc
704	Странное поведение резервирования потоков E1 платой SW-01	alx	alx	"В плате 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
}}}

2. Настройка СУВ потока 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
}}}

3. Режим СУВ 5E1 вернул в значение ""выкл"", в ПЛИС ""на ходу"" загрузил прошивку версии 13.

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

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

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

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

**Предлагаю** попробовать выяснить причины неправильного поведения ПЛИС и устранить их."	баг	closed	средний	1 очередь	ПЛИС (sw)	fixed