Форум: Техническая поддержка

Компьютер работает круглосуточно, а питание экспериментального оборудования (в т. ч. крейт с LTR-35) включается только на время эксперимента (типично - на рабочий день). Перед экспериментом всё включается и проверяется вручную. В частности, я после подачи питания на крейт установил в LTR Manager соединение с ним, щёлкнув мышкой, и проверил отсутствие галочек А и R в строчке с этим крейтом. (Галочки мы особенно внимательно проверили, помня про проблемы от них прошлый раз.)

Вмешательство посторонних лиц, поставивших галочку, крайне маловероятно. Я бы скорее предположил проблемы с интерфейсом LTR Manager: возможно, при щёлкании по крейту с целью установки соединения события мышки "просочились" каким-то нештатным образом за пределы нужной области экрана и повлияли на галочку - так, что она логически установилась, но не отобразилась сразу.

И остаётся вопрос с причиной разбежки по времени в логах ОС и LTR Manager.

По разнице во времени, то больше похоже на какое-то расхождение времени dmesg и системного времени, которое использует LTR Manager.
Предположу, что dmesg использует аппаратный клок (можно посмотреть через вызов hwclock и сравнить с системным), который может отличаться от системного времени, если используется например синхронизация по времени через NTP и т.п.

Роутер входит в экспериментальное оборудование и включается вместе с крейтом или работает всегда?

Это было когда в этот день? В 16:03? Или другое время?

Роутер работает всегда (круглосуточно).
Да, установка соединения с крейтом скорее всего была в 16:03 (в этот день я делал это 1 раз и примерно в это время).
Разбежки системного времени с аппаратным в настоящее время не наблюдается:

$ date; sudo hwclock
Пт 06 янв 2023 16:13:16 MSK
2023-01-06 16:13:16.232969+03:00

Ну как именно dmesg получает время не очень понятно, но в описании опции явно написано про время 'may be inaccurate!'. По этой теме есть ряд обсуждений (например https://serverfault.com/questions/57613 … uMC4wLjA.), где тоже вначале предполагали, что dmesg использует аппаратное время и тоже это не помогло.  Почему так не могу сказать, возможно на уровне ядра нет возможности доступа к системному времени, и видимо для корректной привязки ко времени нужно использовать сообщения системного журнала а не напрямую dmesg. Для вывода сообщений ядра из системного журнала можно использовать journalctl -k (с возможностью выбора интервала с помощью опций -S и -U), можете проверить соответствие времен этим способом.

И если роутер всегда включен, не очень понятно, почему при включении оборудования в 16:03 тоже были пропадания и восстановления сетевого интерфейса?  (причем тогда видимо автоматическое переподключение как и требовалось не запустилось и через 1.5 минуты видимо было ручное подключение).

Да, метки времени, выданные командой journalctl -k, совпали с метками аналогичных событий из лога LTR Manager:

янв 05 16:02:37 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
янв 05 16:02:40 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
янв 05 16:02:52 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
янв 05 16:02:53 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
янв 05 19:09:22 emr102 kernel: nouveau 0000:01:00.0: Direct firmware load for nouveau/nv106_fuc084 failed with error -2
янв 05 19:09:22 emr102 kernel: nouveau 0000:01:00.0: Direct firmware load for nouveau/nv106_fuc084d failed with error -2
янв 05 19:09:22 emr102 kernel: nouveau 0000:01:00.0: msvld: unable to load firmware data
янв 05 19:09:22 emr102 kernel: nouveau 0000:01:00.0: msvld: init failed, -19
янв 05 19:28:56 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
янв 05 19:28:58 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
янв 05 19:29:09 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
янв 05 19:29:11 emr102 kernel: igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

Оказалось, что предыдущий раз проблемы с интерфейсом eno1 возникали 10.11.2022, что было описано в предыдущих сообщениях. И с тех пор компьютер работал непрерывно и ничего подобного не происходило (ни во время работы оборудования, ни когда оно было выключено). Спасибо за разъяснения,
будем дальше разбираться в сути проблемы.

Подскажите, а возможно ли управлять соединением с крейтом (проверять наличие соединения, устанавливать, разрывать) не из графического интерфейса LTR Manager, а с помощью API из своей программы? Это бы полностью решило возникшую у нас проблему - дало бы возможность при пропадании соединения восстанавливать его со сбросом крейта не в случайный момент, а в безопасный с точки зрения логики эксперимента.

Да, все функции, доступные в LTR Manager, можно выполнить с помощью функций ltrapi (он по сути через ltrapi со службой и работает).
Для этого используются функции общей библиотеки ltrapi (https://www.lcard.ru/download/ltrapi.pdf) из раздела "5.3.5 Функции управления подключением крейтов по Ethernet" через управляющее соединение со службой ltrd (4.2.1).

Попробовал сделать в соотвектствии с руководством ltrapi.pdf - не получается. Фрагмент программы

TLTR hsrv;
LTR_OpenSvcControl(&hsrv, LTRD_ADDR_DEFAULT, LTRD_PORT_DEFAULT);

при выполнении приводит к ошибке segmentation error.

При этом всё остальное работает правильно (LTR Manager, крейт и сам модуль LTR-35).

Подскажите, что я делаю не так?
Может ли служба ltrd работать одновременно и с LTR Manager, и с моей программой? Или же LTR Manager нужно закрыть?

После создания структуры TLTR и перед вызовом любых других функций должен быть еще вызов LTR_Init(&hsrv).
Попробуйте, исправит ли это ситуацию.

По управляющим соединениям служба может работать одновременно с несколькими программами, так что закрывать LTR Manager не нужно.

Помогло. Спасибо.