csbug, ага, trust vdisk vd01 трогает только этот vdisk, второй живой не задевает вообще. Но он не чинит RAID, а аварийно поднимает его с разъехавшимися метаданными без гарантии целостности — поэтому сразу и просят слить данные и пересоздать, это не постоянный фикс.
ADarkin, раз baud совпадает, попробуй прогнать тест без pptp — напрямую по tcp через lte, и подними таймауты/ретраи на скаде. Не выйдет, сними дамп с обеих сторон, сразу будет видно где рвётся rtu-кадр.
тут либо считают одновременные сессии, либо просто банят коннект без HWID в хедерах. Железно ограничить число устройств без идентификатора не получится, максимум остаётся эвристика по IP.
Macaronin, PROCHOT правда ни при чём, но глянь "IA: Electrical Design Point/ICCmax" и GT RAPL PL1-PL3 — они у тебя как раз Yes на 30-57% времени, это тот же голод по питанию, только токовый, а не тепловой. Так что БП всё ещё главный подозреваемый, подменяй на заведомо рабочий такой же мощности и смотри, уйдёт ли лимит.
Похоже на правду, серверный rollout часто и правда привязан к IP или id устройства на момент активации — так что смена айпишника вполне могла пересчитать твою группу.
YuuutsunaRyu, дата слишком точно совпадает, чтобы это было совпадением: сначала отключи/удали софт от gigabyte и глянь, не пропадёт ли 51-я. Заодно накатывай прошивку через KSM раз уж собрался — SMART чистый, но диску пять лет, терять нечего.
YuuutsunaRyu, отключения света могли разово всплеснуть 51-й, но раз он стабильно на KC2500 при разном питании — не ОС. Глянь в SMART счётчики Unsafe Shutdowns/Media Errors, и если после прошивки и теста на другом ПК ошибка не уйдёт — меняй диск по гарантии.
тогда пусть на самом FTD прогонят packet-tracer input inside tcp ip-клиента порт внутренний-ip порт detailed — сразу видно, на каком шаге трафик режется. команда доступна через system support diagnostic-cli
раз косяк стабильно на kc2500 — обнови прошивку через Kingston SSD Manager и погоняй тест в другом пеке. если 51-е вылезет и там, дело в диске, меняй по гарантии, даже с чистым SMART
uyshaaaaaa, всё сходится — в скинутом коде нет строки part 'имя_твоего_файла.g.dart' в начале, поэтому _$AppDb пустой класс без сгенерённого миксина, отсюда обе ошибки. Добавь part с точным именем .dart файла и прогони build_runner build ещё раз.
uyshaaaaaa, сама эта строка рабочая, номер часто просто место, где генератор споткнулся, а не где реальная причина. Скинь точный текст ошибки и весь класс таблицы целиком, на глаз тут не угадать.
похоже кеш build_runner протух, раз всё "skipped" и 0 outputs — сначала прогони dart run build_runner clean, потом заново билд. И проверь что в app_db.dart реально есть строка part 'app_db.g.dart'; с точным именем файла.
Андрей Александров, техподдержка не будет отвечать
Сейчас они полностью перегружены Крым законом что надо всех владельцев доменов верифицировать через госуслуги
Андрей Александров, что значит не имеет, какие на странице есть вызовы те он и индексирует, или он на каждый странице должен ещё думать и решать какие запросы индексировать а какие нет
