Станция ОХО. Проблема с потоком.
Как только подключаешь поток к плате PRI, в HW Anomaly вываливаются записи:
103 OBC Anomaly 08#1.
После этого в Hardware and Limits - Main Cabinet потоковая плата обозначена как Absent, accepted.
Пробовал менять плату PRI и менять слот - та же история.
Может кто сталкивался с подобным?

А может быть проблема с внешней стороны потока? Не пробовали менять внешнюю станцию или источник сигнала? И какие приоритеты по синхронизации?

Это происходит даже при физическом завороте потока на самой плате PRA-T2.
Не то процессор виноват, не то кабинет. :-(

А физический заворот потока нельзя делать, если синхронизация берется с этого потока - у процессора крыша может съехать. И что в History table написано на эту тему? Может заблокировано по лицензиям? Можно переключить СОМ-порт в режим вывода сообщений и посмотреть, что выдает ОХО, когда плату вставляете(если это не релиз 1.1). Только РМ5 в этом режиме не работает через СОМ-порт. Это два взаимоисключающих режима работы СОМ-порта.

> А физический заворот потока нельзя делать, если синхронизация берется с этого потока - у процессора крыша может съехать.

Процессор к синхронизации имеет только то отношение, что задает приоритеты, откуда ее брать. Дальше это уже дело железа, хотя и расположенного на плате CPU, но являющегося отдельной от управляющего процессора логически законченной частью. Если синхронизация берется от этого же потока, то единственное, к чему приведет этот заворот - периодические ее срывы, но уж никак к тому, что плата будет показываться как Absent.

ТО: avk. Теоретически вы, наверное, правы, но практическая реализация теории не всегда бывает успешной. Яркий пример - процессор CPU3 step1 от 4400, который после заворота на плате PRA, входил в ступор, и не реагировал ни на какие сигналы, помогал только ручной сброс. Производитель признал проблему и быстро был выпущен CPU3 step2 на замену, в котором эта проблема решена. Существует проблема со стартом CPUe-1, когда процессор получает от чипсета время 0ч 0мин 0день 0месяца 0года. А это бывает, когда отсутствует литиевая батарейка на плате или контакт в пайке держателя батареи. Но это, правда, не имеет отношения к синхронизации.

> Теоретически вы, наверное, правы, но практическая реализация теории не всегда бывает успешной.

Но в данном конкретном случае теория как раз подтверждается практикой - означенный заворот на OXO ваш покорный слуга делал без каких-либо последствий для процессора.
Да и, по-моему, неуместо сравнивать 4400 с OXO.

> Существует проблема со стартом CPUe-1, когда процессор получает от чипсета время 0ч 0мин 0день 0месяца 0года.

И при этом еще оно не меняется, т.е. RTC не работает. С означенной проблемой я знаком отнюдь не понаслышке :) Только проблема эта не столько аппаратная, сколько софтверная - начальный линуксовый скрипт пытается синхронизировать время в ядре с временем в RTC, а программка, которая эта делает (стандартная линуксовая, кстати - это я на всякий случай, чтобы не было претензий к Алкателю), ждет, когда в RTC оно тикнет хотя бы раз. И не дожидается, после чего аппаратный watch dog перегружает процессор, и все начинается с самого начала. А ведь могла бы эта программка вместо вхождения в бесконечный цикл после определенного таймаута ставить какую-нибудь дату, заведомо более раннюю, чем дата написания этой программки, ан нет.

А все-таки "et" оказывается прав, кривой это софт, и у процессора правда крыша едет.
Если интересно можно почитать здесь (писать по новой неохота): http://a4400.spb.ru/forum/viewtopic.php?topic=1222&forum=1&11

На телексе выяснили, что проблема с версией ПО 310/028.003. Проблема отсутсвует в 310.020 и в 4.0.

Все-таки, при включении реально работающего потока происходит то же самое.
Привезли другую станцию, запустили - все ОК, поток поднимается нормально.
Если включить этот же поток в 310/028 - глюк.