Кстати, возможно проблема именно с этой видюхой. У меня были глюки с RX580 2048SP, но она выдавала хоть какое-то изображение, правда в розовых тонах всё. Причём, если зайти в биос, но цвета норм, и после загрузки винды с дровами цвета норм, а на UEFI заставках всё розовое. Устанавливал винду на встройке, подкинул 580 и уже думал ппц, но дрова скачались сами и изображение нормализовалось. Правда, поставил потом старушку 750Ti, на ней проблем нет, да её и оставил, хотя 580 в винде вроде как норм работает уже после установки дров.

Было так:

См. здесь.

Я пробовал разные видяхи (заранее все рабочие): RTX3070, RX6600XT, GTX970.
У меня нет ничего, что можно воткнуть в PCIx16, чтобы оценить его работоспособность. Контакты все внешне целые, питание на видюху подаётся, но её не видно не в БИОС, не в Винде.

Добавлено спустя 3 минуты 36 секунд:

Но в таком случае винда должна видеть вторую видюху. У меня ничего нет из неопознанных устройств в диспетчере.

Поставил предпоследнюю с гитхаба. разницы ноль, только интерфейс не через приложение в трее, а через Realtek Audio Console стал. А так функционал не изменился и ничего нового не добавилось. Все так же стерео либо квадрофонический. Вобщем наверное либо мой экземпляр платы неудачный, либо китайцы были очень ленивые и не стали полноценно разводить аудио чип.

Только что проверил, при подключенной дискретной видюхе и настройках в биосе по-умолчанию, если воткнуть кабель HDMI в слот материнки, то никакого изображения нет, так как приоритет отдаётся дискретной карте, как это обычно и есть на системниках. Если у тебя при этом выводится изображение через встройку, очевидно, что мать не видит видюху.

Кстати, забыл отписаться, что пробовал установить помпу на кристалл - без вариантов: упирается в конденсаторы слева. Только кулер с маленькой площадкой туда можно запихнуть.

Если есть возможность вернуть плату продавцу или обменять её на исправную, то сделайте это.
Мне попадалась такая плата с сопротивлением проводника одной из пар первого лейна порядка 16 Ом на землю.
Так как все сигнальные линии этого слота подключены напрямую к процессору, ремонт, не предполагающий его замены, невозможен.
Есть мнение, что к появлению такого дефекта приводит некорректная (обратной стороной) установка в слот какого-то популярного райзера. Не могу уверенно прокомментировать эти слухи - по логике, физически, при таком ошибочном подключении такой эффект не должен возникать.
Впрочем, это, наверное, неважно, если это или что-то подобное уже произошло с Вашей платой.

Методику проверки линий PCIe "на коленке" я описывал здесь.

На материнке с 11980HK ES в биосе, как на декстопах, есть параметр, который отвечает за запуск материнки при подачи питания?
Не нашел такого пункта...

Есть, но включение не с разу, а через 1-5 минут. Но это уж лучше, чем просто по таймеру в конкретное время, что там тоже есть.

Advanced / S5 RTC Wake Settings / Dynamic Time - 1

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

Advanced / RC ACPI Settings / Wake system from S5 / Enabled

Это "ноутбучный" BIOS, и настройки с тремя вариантами выбора поведения системы после подачи питания (выключено, включено, состояние до отключения питания) здесь нет.
Однако, с помощью настройки Chipset -> PCH-IO Configuration -> State After G3 можно получить два варианта:
S5 State - выключено, установлено по умолчанию;
S0 State - включено.

у меня не живут

Добавлено спустя 40 минут 19 секунд:
Посмотрел что китайцы пишут в своих магазинах.
Получается что проблема с отвалом дискретного видео на платах Erying наблюдается для i9-10980HK и всех инженерников 11 поколения.
С остальными все в порядке.

У меня плата с "CPU 0000 ES 2.6GHz". Видеокарта RTX A2000. Отвалов нет. Внутренний GPU отключен, стоит два SSD в обоих слотах. Но... Нет с "сна" как такового. В заданный промежуток простоя выключается монитор, потребление всего блока остается на уровне 40 вт. После "просыпания" - работает с того же места что и раньше.

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

надо чтобы кто-то у кого все норм сделал доброе дело - сфотал все окошки биоса.
100% ответ будет найден при сравнении.

Хм, а разве отвал видео не только в стресс тестах? Я замечал только во время них. Причём, только если хоть один множитель 49 и больше и оффсет -110. Поставил 48 максимум на ядро, оффсет -110 и в тестах видео не виснет, и танки не вылетают после боя. Все настройки стоковые, только множители, оффсет процессора и хмп настраивал. Ринг не трогал, из-за него тоже отвал видюхи ловил и забил, на температуру он не влияет никак.

Кстати, висло в основном на воздухе, на воде стало стабильнее, мне кажется это с температурой тоже связано

https://1drv.ms/u/s!ApFYLYt6tVaEshktkKY ... e?e=P0aCgJ

Продавец с алика прислал бетку нового биоса на erying( в моем случае 11800 es)

Tips: It is risky to update the BIOS. Please be careful. During the execution of the BIOS update program, do not interrupt the update or restart the BIOS.

Procedure for updating the BIOS:

Select an ordinary USB flash drive and format it into FAT32 format. PE or DOS and other boot disks cannot be used.

Copy the extracted EFI folder to the root directory of the USB flash drive used to brush the BIOS.

Insert the USB disk into the USB interface of the motherboard to brush the BIOS, and press Delete key on the keyboard to enter the motherboard BIOS interface after startup;

Enter the SAVE&EXIT module on the BIOS screen, select the boot option of a USB flash drive starting with UEFI, and confirm the input.
Five, at this point, you will enter UEFI boot shell interface, in this interface will automatically execute the process of swiping the motherboard BIOS, brushing the BIOS can not interrupt the process of swiping, otherwise it will cause the motherboard boot is not bright;

21:36
avatar
ShenZhenHuaQiangBei YiYi Factory store Store
Vi. The BIOS brushing process varies from dozens of seconds to several minutes, please wait patiently...

Seven, when the motherboard has a green upgrade update is completed, it means that the motherboard BIOS update is completed;

After updating the BIOS, the motherboard must directly cut off the AC power supply, short connect the CLR pin on the motherboard for 3 seconds, power on and boot into the BIOS, press F9 to load the optimization value, press F10 to save and restart before normal use.

Хотелось бы узнать как продвигаются ваши труды по устранению данного косяка ?
Я так же являюсь представителем данной проблемы.

Месяц назад тут этот биос был. Попробуйте - прошейте, правда есть ньюанс

Есть смысл покупать "Радиатор для плат со встроенным мобильным процессором" ? https://recold.ru/product/materinskaya- ... sessorom-h
Корпус с обдувом обратной стороны материнской платы .

Уж лучше может радиаторы купить получше - толка больше будет https://aliexpress.ru/item/1005005190035408.html
Сам не ставил.

Уже купил такие https://aliexpress.ru/item/100500525725 ... 4aa6GK0tIu
Спрашиваю именно из-за "Радиатор для плат со встроенным мобильным процессором"

Не будет.
Во-первых, в этом BIOSе только "всегда открытых" экранов настроек, отображающихся независимо от выбора значений на других экранах, порядка 130 штук. Едва ли кто-нибудь возьмётся их фотографировать.
Во-вторых, эксперименты показывают, что после полного сброса настроек на значения по умолчанию (и установки одного-двух "обязательных" для стабильной работы значений) разные экземпляры платы - точнее, разные сборки у разных владельцев плат одной и той же модели - ведут себя по-разному.
Например, мне для того, чтобы наблюдать этот "отвал", нужно умышленно задать определённые значения в этом сетапе или установить драйвер видеокарты определённой версии - иначе, "просто так", он не проявляется. А Eldreamer с точно такой же платой и точно такими же настройками так пока и не преуспел в том, чтобы избавиться от этого "отвала".

С моей точки зрения, такая картина однозначно указывает на то, что причиной "отвала" является что-то во внешнем окружении, "за пределами" платы.
Ведь у каждого из нас, владельцев этих плат, это окружение уникально: разные видеокарты, разные блоки питания, разная память, разные SSD. О разных решениях для охлаждения процессора, хаба и компонентов источника питания я даже не упоминаю - они очевидно разные.
Этих внешних факторов слишком много. Более того, они могут действовать не по отдельности, а в невероятном множестве разных сочетаний друг с другом. И если кто-то из владельцев говорит, что он попробовал, например, два разных блока питания разных моделей, и выяснил, что на вероятность возникновения "отвала" блок питания никак не влияет, то из этого факта нельзя делать никаких "глобальных" выводов. Да, на этой, конкретной сборке при смене одного БП конкретной модели на БП другой конкретной модели "отвалы" не исчезают (или не появляются, если их не было). Но это совершенно не значит, что на какой-то другой сборке, с другим внешним окружением платы, какой-то совсем другой блок питания не может быть причиной проблемы.

В ситуациях вроде этой есть два базовых подхода к решению проблемы.
Первый - сбор статистики и поиск закономерности после получения определённого количества данных.
На практике, минимум данных в сообщении об "отвале" должен включать в себя указание моделей БП, памяти, SSD, краткую характеристику решений по СО процессора, хаба и ИП, интервал потребляемой процессором мощности, в котором вероятность возникновения "отвала" максимальна. Дополнительно, может сильно пригодиться краткое описание особенностей проявления "отвала". Например, если он чаще проявляется при низких частотах работы ядер процессора, чем при высоких.
Сколько нужно таких сообщений для того, чтобы начинать их анализировать, искать закономерности? На мой взгляд, штук 10, не меньше. Естественно, это должны быть сообщения о сбоях на разных сборках, на разных платах, а не при разных режимах работы одной платы.
Сможем ли мы набрать такое количество подобного рода описаний "отвала"? Затрудняюсь сказать. Судя по динамике в этом обсуждении, 10 штук "правильных" сообщений мы наберём разве что через 2-3 месяца.
Второй подход - "безадресный". В данном случае, более-менее обоснованные попытки изменения определённых настроек в расчёте на то, что какое-нибудь из таких изменений поможет преодолеть воздействие неблагоприятных факторов и предотвратить проявление "отвала". Это то, чем уже какое-то время здесь занимаюсь я.
Слабая сторона этого подхода состоит в том, что для его успешного применения необходимо, чтобы предлагаемые изменения настроек попробовали все, у кого наблюдаются сбои. Потому что если предположить, что причины "отвала" для каждой сборки отличаются, то "не помогающая" для одной сборки настройка будет навсегда "забракована", как бесполезная. Хотя на какой-то другой сборке она вполне могла бы дать положительных эффект, решить проблему.