Есть ли простой, безопасный способ вызвать блокировку графического процессора на восприимчивом компьютере?

Отличный вопрос.

Рабочие нагрузки

В каталоге / usr / share / xdiagnose / workloads есть набор рабочих нагрузок, предназначенных для тренировки вашей графической системы для запуска блокировок.

$ ls /usr/share/xdiagnose/workloads/
README                       do_monitor_rotation_loop
do_chws_loop*                do_screensaver_loop*
do_cpu_spin_loop             do_video_loop*
do_disk_write_loop           do_vtswitch_loop*
do_glx_loop*                 repro.sh
do_kernel_compile_loop       run_workloads
do_monitor_disable_loop*     youtube-loop.html
do_monitor_resolution_loop*  youtube-reload.html

Обратите внимание, что для их запуска вам нужно пройти «run». Например :

$ do_glx_loop run

Без аргументов сценарии будут отображать использование. Частично это для безопасности (в случае, если люди просто слепо запускают скрипты), но в основном это для того, чтобы поддерживать API скриптов в чистоте.

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

Заметьте, я сам не тестировал эти супер-тесты, поэтому не могу обещать, что они не содержат ошибок. Но это довольно короткие и простые сценарии, которые, надеюсь, легко исправить, и исправления приветствуются.

Также обратите внимание, что они вполне могут вызвать блокировки, не связанные с той, которую вы пытаетесь решить. Блокировки графического процессора, как правило, выглядят так же, как у нетренированного глаза, так как они имеют те же симптомы, более или менее.

Logs

Если вы используете Intel Graphics, вам нужен каталог / sys / kernel / debug / dri / 0 / i915_error_state. Это снимок состояния регистра во время зависания, и в верхней его части содержатся некоторые коды ошибок. IPEHR, PGTBL_ER, ESR, EIR. Сопоставьте эти коды, чтобы увидеть, есть ли у вас такая же или похожая ошибка.

Если вы не используете Intel Graphics (как в данном случае), или если вы не видите сгенерированные файлы i915_error_state, то вам стоит посмотреть dmesg и /var/log/kern.log. Иногда с блокировками GPU они будут указывать, что блокировка GPU была вызвана или в.

Драйвер -ati с открытым исходным кодом имеет radeontool и avivotool, которые захватывают регистровые состояния. Это в первую очередь для opensource -ati, но инструменты также должны работать с -fglrx. Я никогда не видел, чтобы он запрашивал ошибку -fglrx, но это точно не повредит.

Тестирование

Для всех драйверов следующим шагом обычно является начало тестирования как более новой, так и более старой версии драйвера. Для проприетарных драйверов вы можете проверить x-updates ppa, но, вероятно, вам придется загрузить и вручную установить драйвер с веб-сайта производителя (и при этом испортить упаковку вашей системы). Для драйверов FOSS, таких как -intel, -nouveau, -ati, это означает, что нужно тестировать либо новые ядра, либо новые mesa. Мы предоставляем упакованные сборки более новых ядер по адресу http://kernel.ubuntu.com/~kernel-ppa/mainline/ . Для mesa существуют различные PPA, такие как xorg-edgers. Я также готовлю обновление 8.0.3 для точного, который, как мы полагаем, исправляет ряд блокировок для Intel Graphics.

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

Содействие

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

Что касается изменений в самих скриптах, то тоже весьма приветствуется. Присылайте мне изменения, как вам удобно - в виде патчей, ветки bzr или git или даже просто копий скрипта. Если вы планируете внести много изменений, предпочтительным способом будет ветка bzr с предложением о слиянии; учебные пособия о том, как это сделать, доступны на code.launchpad.net, или вы можете поймать меня на IRC, если у вас есть вопросы.

Или, если вы не готовы углубиться в кодирование, но хотели бы отмечать ошибки или области, где требуется больше функциональных возможностей, вы можете подавать отчеты об ошибках обычным способом (ubuntu-bug xdiagnose).

Быстрые исправления

Если вы не заинтересованы в выполнении какой-либо из вышеупомянутых отладок, вот несколько случайных советов:

Для проприетарных драйверов попробуйте удалить и очистить их полностью из вашей системы, а затем переустановить с нуля. Это, к сожалению, «решает» много ошибок ...

Для драйверов FOSS есть различные переключатели ядра, с которыми вы можете поиграть. Для ошибок 3D / mesa также есть возможность настроить различные параметры.

И наконец

Наконец, один запрос ... пожалуйста, не отправляйте отчеты об ошибках на Launchpad о «случайных зависаниях», пока вы не выполнили хотя бы небольшое уловление, как описано выше. В противном случае вы бы просто добавили шум.

Мы стараемся выискивать хорошо изученные сообщения об ошибках; мы находим, что они дают более высокий удар по доллару, и гораздо более вероятно, что в итоге получится реальное исправление для дистрибутива.