Created attachment 9354 [details] Вывод inxi -G Имеется ноутбук с Ryzen 5 (4600) + дискретная Nvidia GTX 1650. SL 9.1 не запускается в режиме Live-cd: после старта X-сервера, через пару секунд система принудительно завершает работу и отключает питание (картина аналогичная shutdown - завершает все службы и вырубает питание). Если произвести установку, то графический ражим стартует нормально, но при попытке запустить alterator-x11 или обновить ядро (update-kernel) воспроизводится проблема, аналогичная попытки запуска livecd.
Created attachment 9355 [details] вывод make-initrd перед выключением ноута Так же проблема воспроизводится при запуске make-initrd, видимо поэтому у меня и не получилось обновить ядро.
не сказано что за ноутбук имеется.
(Ответ для Anton Farygin на комментарий #2) > не сказано что за ноутбук имеется. Не имеет значения. Проверял на следующих моделях: HP Pavilion Gaming 15-ec1094ur HP Pavilion Gaming 15-ec1087ur Lenovo IdeaPad 3 Gaming 15ARH05 ASUS TUF Gaming A17 FX706II-H7028 Везде ситуация повторилась один в один.
Такое поведение только на Simply ? на K 9.1 система как себя ведёт после установки ?
(Ответ для Anton Farygin на комментарий #4) > Такое поведение только на Simply ? на K 9.1 система как себя ведёт после > установки ? Не только Simply, но и НеРабочая станция 9.1 - livecd не стартует графика, установщик запускается только в безопасной графике (драйвер vesa). На К 9.1 все прекрасно - и в livecd загружает без сбоев, и после установки коректно работает и обновляется. Х работает стабильно , alterator-x11 запускается, определяет дискретную карту.
на simply какой драйвер запускается для иксов на установленной системе ? Присоедините sosreport, пожалуйста.
(Ответ для Anton Farygin на комментарий #6) > на simply какой драйвер запускается для иксов на установленной системе ? > > Присоедините sosreport, пожалуйста. Увы, не могу. Ноут вырубается при попытке сбора данных о ядре. =(
можно под K 9.1
(Ответ для Anton Farygin на комментарий #8) > можно под K 9.1 Вот https://disk.yandex.ru/d/gEvezkTKhiKTjw
мы собрали конфиг, на котором подобная проблема воспроизводится и поставили её в очередь на исправление.
на ядре un-def модуль nouveau тоже падает. ALT образование вообще не загрузился в livecd mode.
Возможно, это разные проблемы т.к. в нашем случае ryzen довольно старый. Для начала попробуем исправить её.
(Ответ для Anton Farygin на комментарий #12) > Возможно, это разные проблемы т.к. в нашем случае ryzen довольно старый. Для > начала попробуем исправить её. Нет одна и та же. Я вчера, скажем так, по наводке @cas, воспроизвел проблему на своей конфигурации. Альт Образование в livecd не грузится, да еще и зависает во время установки (инсталлятор грузится с драйвером vesa/fbdev). Ситуация полностью аналогична и на (Не)Рабочей Станции 9.1.
(Ответ для Михаил на комментарий #13) > > Нет одна и та же. Не могли бы Вы проверить запуск инсталлятора на проблемной машине с отключенным IOMMU? Для этого в меню grub при загрузке нужно нажать "e" и строку параметров передаваемых ядру дополнить: amd_iommu=off Если после этого система загрузится и будет работать стабильно, можно собрать sosreport c проблемного дистрибутива.
(Ответ для nickel@altlinux.org на комментарий #14) > (Ответ для Михаил на комментарий #13) > > > > > Нет одна и та же. > > Не могли бы Вы проверить запуск инсталлятора на проблемной машине с > отключенным IOMMU? > > Для этого в меню grub при загрузке нужно нажать "e" и строку параметров > передаваемых ядру дополнить: amd_iommu=off > > Если после этого система загрузится и будет работать стабильно, можно > собрать sosreport c проблемного дистрибутива. Какого дистрибутива из 3 проблемных? В режиме livecd достаточно будет загрузится для сбора sosreport?
(Ответ для nickel@altlinux.org на комментарий #14) > (Ответ для Михаил на комментарий #13) > > > > > Нет одна и та же. > > Не могли бы Вы проверить запуск инсталлятора на проблемной машине с > отключенным IOMMU? > > Для этого в меню grub при загрузке нужно нажать "e" и строку параметров > передаваемых ядру дополнить: amd_iommu=off > > Если после этого система загрузится и будет работать стабильно, можно > собрать sosreport c проблемного дистрибутива. Нет, при загрузке с этим параметром поведение системы не меняется. Те же проблемы - не могу ни обновить ядро, не составить sosreports, не зайти в alterator-x11
Есть идеи? Нужно железо?
(Ответ для AEN на комментарий #17) > Есть идеи? > Нужно железо? Идеи есть, нужно время. Необходимость закупки идентичного железа пока не подтверждена. С тем, что есть у нас тоже проявляется баг, и, что интересно, только на SL отключение IOMMU не помогает, в отличие от других дистрибутивов, протестированных на нашей конфигурации.
(Ответ для nickel@altlinux.org на комментарий #18) > (Ответ для AEN на комментарий #17) > > Есть идеи? > > Нужно железо? > > Идеи есть, нужно время. > Необходимость закупки идентичного железа пока не подтверждена. > С тем, что есть у нас тоже проявляется баг, и, что интересно, только на SL > отключение IOMMU не помогает, в отличие от других дистрибутивов, > протестированных на нашей конфигурации. Образование 9.2 проверяли? http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/x86_64/
(Ответ для AEN на комментарий #19) > Образование 9.2 проверяли? > http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/ > x86_64/ Именно 9.2 - пока нет, но проверю.
(Ответ для nickel@altlinux.org на комментарий #20) > (Ответ для AEN на комментарий #19) > > > Образование 9.2 проверяли? > > http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/ > > x86_64/ > > Именно 9.2 - пока нет, но проверю. Спасибо. Ждем.
(Ответ для AEN на комментарий #21) > (Ответ для nickel@altlinux.org на комментарий #20) > > (Ответ для AEN на комментарий #19) > > > > > Образование 9.2 проверяли? > > > http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/ > > > x86_64/ > > > > Именно 9.2 - пока нет, но проверю. > Спасибо. Ждем. Если бага там воспроизведется, чего я ожидаю, посмотрите на стартерах с 5.10 и 5.4, пожалуйста.
Нет новостей?
(Ответ для AEN на комментарий #23) > Нет новостей? Обнадеживающих пока, к сожалению, нет. Зависают на этой связке и SL9, и education 9.2, и регулярки c std-def и un-def ядром. Разбираемся.
(Ответ для Михаил на комментарий #0) > Если произвести установку, то графический ражим стартует нормально, но при > попытке запустить alterator-x11 или обновить ядро (update-kernel) > воспроизводится проблема, аналогичная попытки запуска livecd. попробуйте выполнить inxi -G Я так и не понял какая графика работает. Встроенная (интернет говорит, что она у этого процессора есть) или дискретная?
C nomodeset пробовали грузиться? А с 'nomodeset nouveau.modeset=0'?
(Ответ для Антон Мидюков на комментарий #25) > (Ответ для Михаил на комментарий #0) > > Если произвести установку, то графический ражим стартует нормально, но при > > попытке запустить alterator-x11 или обновить ядро (update-kernel) > > воспроизводится проблема, аналогичная попытки запуска livecd. > > попробуйте выполнить > inxi -G > > Я так и не понял какая графика работает. Встроенная (интернет говорит, что > она у этого процессора есть) или дискретная? inxi -G выполнял. Вывод в первом же комменте закреплен. Только вот я запускал эту утилиту на станции К (она напоминаю, работает на этой конфигурации идеально). Естественно есть и встроенная (vega 6) и дискретная (1650Ti). Сч проприетарными драйверами по умолчанию все работает на встроенной,и через NV_PRIME_RENDER_OFFLOAD перключает на дискретную нужное приложение. Как оно нам на опенсорсном драйвере - пока не понял, ибо все сборки АЛЬТ с опенсорсными дровами отказываются даже запускаться.
(Ответ для Антон Мидюков на комментарий #26) > C nomodeset пробовали грузиться? А с 'nomodeset nouveau.modeset=0'? nomodeset nouveau.modeset=0 - вот что не пробовал, то не пробовал. Пока попробовать возможности нет.
Баг частично исправлен в задании http://git.altlinux.org/tasks/273537/ (уже прошло в p9) Частично, потому что исправление работает только для установленной системы, livecd и инсталлятор все равно не запускаются (запуск возможен только с nouveau.modeset=0 или modprobe.blacklist=nouveau) Исправление было проверено также на Lenovo IdeaPad 3 Gaming 15ARH05 Причина неисправности была вот в чем: Мидюков Антон писал(а): > Проблема нашего firmware-linux была в том, что не создавались симлинки. Нужное фирмвари было заменено на симлинк, а симлинк при сборке пакета создан не был.
(Ответ для Slava Aseev на комментарий #29) > Баг частично исправлен в задании http://git.altlinux.org/tasks/273537/ > (уже прошло в p9) > > Частично, потому что исправление работает только для установленной системы, > livecd и инсталлятор все равно не запускаются (запуск возможен только с > nouveau.modeset=0 или modprobe.blacklist=nouveau) > Исправление было проверено также на Lenovo IdeaPad 3 Gaming 15ARH05 > > Причина неисправности была вот в чем: > Мидюков Антон писал(а): > > Проблема нашего firmware-linux была в том, что не создавались симлинки. Нужное фирмвари было заменено на симлинк, а симлинк при сборке пакета создан не был. Отлично! @aen вроде обещал, что образ symply linux будет пересобран, как только баг будет исправлен =)
(In reply to Михаил from comment #30) > (Ответ для Slava Aseev на комментарий #29) > > Баг частично исправлен в задании http://git.altlinux.org/tasks/273537/ > > (уже прошло в p9) > > > > Частично, потому что исправление работает только для установленной системы, > > livecd и инсталлятор все равно не запускаются (запуск возможен только с > > nouveau.modeset=0 или modprobe.blacklist=nouveau) > > Исправление было проверено также на Lenovo IdeaPad 3 Gaming 15ARH05 > > > > Причина неисправности была вот в чем: > > Мидюков Антон писал(а): > > > Проблема нашего firmware-linux была в том, что не создавались симлинки. Нужное фирмвари было заменено на симлинк, а симлинк при сборке пакета создан не был. > > Отлично! @aen вроде обещал, что образ symply linux будет пересобран, как > только баг будет исправлен =) Он еще не исправлен полностью. Но надеюсь и жду.
(Ответ для AEN на комментарий #31) > (In reply to Михаил from comment #30) > > (Ответ для Slava Aseev на комментарий #29) > > > Баг частично исправлен в задании http://git.altlinux.org/tasks/273537/ > > > (уже прошло в p9) > > > > > > Частично, потому что исправление работает только для установленной системы, > > > livecd и инсталлятор все равно не запускаются (запуск возможен только с > > > nouveau.modeset=0 или modprobe.blacklist=nouveau) > > > Исправление было проверено также на Lenovo IdeaPad 3 Gaming 15ARH05 > > > > > > Причина неисправности была вот в чем: > > > Мидюков Антон писал(а): > > > > Проблема нашего firmware-linux была в том, что не создавались симлинки. Нужное фирмвари было заменено на симлинк, а симлинк при сборке пакета создан не был. > > > > Отлично! @aen вроде обещал, что образ symply linux будет пересобран, как > > только баг будет исправлен =) > > Он еще не исправлен полностью. Но надеюсь и жду. Так судя из отчета как раз-таки неполностью подразумевает, что как раз-таки нормальная работа live-режима и установщика невозможна, в виду необходимости установки обновлений. А после пересборки образ уже будет включать обновления с исправлениями, или я опять все упростил?
Упростили.
(Ответ для Михаил на комментарий #32) > Так судя из отчета как раз-таки неполностью подразумевает, что как раз-таки > нормальная работа live-режима и установщика невозможна, в виду необходимости > установки обновлений. А после пересборки образ уже будет включать обновления > с исправлениями, или я опять все упростил? Нет. Проблема в сборке live и инсталятора. Может, что-то лишнее в initrd. Нужно разбираться. Пока не разберёмся, смысла пересобирать образ нет.
Удалось вытащить лог из вырубающегося livecd. Вырубается, вероятно, из-за температуры в 511 C: Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: therm: temperature (511 C) hit the 'fanboost' threshold Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: therm: temperature (511 C) hit the 'downclock' threshold Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: therm: temperature (511 C) hit the 'critical' threshold Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: therm: temperature (511 C) hit the 'shutdown' threshold Но больше интересен вот этот момент: Костригин Николай писал(а): > Возможно, стоит обратить внимание и на вот этот вывод (он предваряет все последующие crash-репорты ядра): >Jun 10 22:23:58 localhost.localdomain kernel: pcieport 0000:00:01.1: Data Link Layer Link Active not set in 1000 msec >Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) >Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) >Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) >Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: tmr: stalled at ffffffffffffffff >Jun 10 22:23:58 localhost.localdomain kernel: ------------[ cut here ]------------ >Jun 10 22:23:58 localhost.localdomain kernel: nouveau 0000:01:00.0: timeout >Jun 10 22:23:58 localhost.localdomain kernel: WARNING: CPU: 0 PID: 1104 at drivers/gpu/drm/nouveau/nvkm/subdev/bar/g84.c:38 g84_bar_flush+0xcb/0xe0 [nouveau] > > По этой проблеме есть целые простыни: > > https://forums.developer.nvidia.com/t/bug-cant-change-power-state-from-d3cold-to-d0-config-space-inaccessible-stuck-at-boot/112912 > > https://www.spinics.net/lists/dri-devel/msg270720.html > ссылается на > https://bugzilla.kernel.org/show_bug.cgi?id=209179 > > который почти один в один повторяет наш случай, но не получил развития на kernel.org Костригин Николай писал(а): > https://patchwork.kernel.org/project/dri-devel/patch/20191017121901.13699-1-kherbst@redhat.com/ > > вот такой патч обсуждали для мостов intel. > > <TL;DR> Читать в самом низу, там приводится quirk для ноутов lenovo и подробно объясняется корень проблемы. > На первый взгляд,хоть у нас и не Intel, может пригодиться Выяснилось, что с параметром nouveau.runpm=0 livecd запускается (и многие проблемы также пропадают из логов)
Как оказалось, багу с температурой в 511С уже 2 года: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/445 Проблема там в том, что при каких-то состояниях gpu thermal sensor может вернуть -1 (т.е. 0xffff...) и после наложения маски 0x1ff (9 бит для температуры) мы получаем те же самые 0x1ff (т.е. 511 градусов)
В Сизифе можно проверить со сборкой http://webery.altlinux.org/task/279907
Проблема исправлена в propagator 20210721-alt1, ждем пересобранные образы. Проверить можно на регулярных сборках: https://mirror.yandex.ru/altlinux-nightly/snapshots/20210727/
Закрываем?
(Ответ для AEN на комментарий #39) > Закрываем? Учитывая, что propagator 20210721-alt1 уже в p9, думаю - можно. Слава, Егор, спасибо! Михаил, если вдруг проблема для Вас не решена - переоткройте. Спасибо за багрепорт.
Коллеги, Михаил, большое спасибо!
