Excelente pregunta
Cargas de trabajo
El directorio / usr / share / xdiagnose / workloads tiene un conjunto de cargas de trabajo diseñadas para ejercitar su sistema de gráficos para activar bloqueos.
$ 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
Tenga en cuenta que para ejecutarlos debe pasar 'ejecutar'. P.ej:
$ do_glx_loop run
Sin argumentos, los scripts mostrarán el uso. En parte eso es por seguridad (en caso de que las personas simplemente ejecuten los scripts a ciegas), pero principalmente es para mantener ordenada la API de los scripts.
Los que he protagonizado son probablemente los mejores para empezar. Comenzaría ejecutando solo un script a la vez y lo dejaría pasar unas horas. Si su sistema sobrevive lo suficientemente bien, intente ejecutar dos o más simultáneamente.
Tenga en cuenta que no los he probado demasiado, así que no puedo prometer que estén libres de errores. Pero son scripts bastante cortos y simples, así que espero que sean fáciles de arreglar, y los parches son bienvenidos.
También tenga en cuenta que es muy probable que puedan desencadenar bloqueos no relacionados con el que está tratando de resolver. Los bloqueos de GPU generalmente se ven idénticos al ojo no entrenado ya que tienen exactamente los mismos síntomas, más o menos.
Registros
Si está en Intel Graphics, hay un / sys / kernel / debug / dri / 0 / i915_error_state que desea. Esta es una instantánea del estado del registro en el momento del bloqueo, y la parte superior contiene algunos códigos de error. IPEHR, PGTBL_ER, ESR, EIR. Haga coincidir esos códigos para ver si tiene el mismo error o un error similar.
Si no está en Intel Graphics (como en este caso no lo está), o si no está viendo los archivos i915_error_state generados, entonces dmesg y /var/log/kern.log son lo que debe mirar. A veces, con los bloqueos de gpu, indicarán por qué se produjo el bloqueo de la GPU.
El controlador de código abierto -ati tiene radeontool y avivotool, que capturan estados de registro. Estos son principalmente para el código abierto -ati, pero las herramientas también deberían funcionar con -fglrx. Nunca he visto que solicite un error -fglrx, pero ciertamente no puede hacer daño.
Pruebas
Para todos los controladores, el siguiente paso suele ser comenzar a probar versiones más nuevas o más antiguas del controlador. Para los controladores propietarios, puede consultar el x-updates ppa, pero probablemente tendrá que descargar e instalar manualmente el controlador desde el sitio web del proveedor (y estropear el paquete de su sistema al hacerlo). Para controladores FOSS como -intel, -nouveau, -ati, eso significa probar los núcleos más nuevos o la mesa más nueva. Proporcionamos compilaciones compiladas de núcleos más nuevos en http://kernel.ubuntu.com/~kernel-ppa/mainline/ . Para la mesa, hay varios PPA, como xorg-edgers. También estoy en proceso de preparar una actualización 8.0.3 para precisión, que creemos soluciona una serie de bloqueos para Intel Graphics.
En cualquier caso, no te detengas cuando encuentres una versión que funcione. Pruebe otras versiones entre su versión de trabajo y la versión rota. Si puede reducir el soporte a dos versiones adyacentes, eso puede ser de gran ayuda para los desarrolladores al aislar qué parche causó la regresión.
Contribuyendo
A medida que avanza en la resolución de problemas, puede detectar errores o encontrar mejoras para los scripts o documentos. Las contribuciones a cualquiera de estos son bienvenidas. Con los documentos de wiki, ¡simplemente adelante y edite! Intento actualizarlos al menos una vez al año, pero no siempre lo hago, y el próximo usuario que visite la página seguramente apreciará su esfuerzo para mejorarlos.
Para los cambios en los scripts en sí, también bastante bienvenido. Envíeme los cambios como se sienta cómodo, como parches, una rama bzr o git, o incluso solo copias del script. Si planea hacer muchos cambios, una rama bzr con una propuesta de fusión es la forma preferida; los tutoriales sobre cómo hacer esto están disponibles en code.launchpad.net, o siéntase libre de encontrarme en IRC si tiene alguna pregunta.
O, si no está listo para profundizar en la codificación pero desea marcar errores o áreas donde se necesita más funcionalidad, puede presentar informes de errores de la manera habitual ( ubuntu-bug xdiagnose).
Arreglos rápidos
Si no está interesado en realizar ninguna de las depuraciones anteriores, aquí hay algunos consejos al azar:
Para controladores propietarios, intente desinstalarlos y purgarlos completamente de su sistema, luego reinstale desde cero. Desafortunadamente, esto "resuelve" muchos errores ...
Para los controladores FOSS, hay varios conmutadores de kernel con los que puede jugar. Para los errores 3D / mesa, también hay driconf para ajustar varias configuraciones.
Finalmente
Finalmente, una solicitud ... por favor, no envíe informes de errores a Launchpad sobre "bloqueos aleatorios" hasta que haya realizado al menos un poco de investigación como se describe anteriormente. De lo contrario, solo estarías aumentando el ruido.
Intentamos obtener informes de errores bien investigados; descubrimos que estos ofrecen una mayor inversión por el dinero, y es mucho más probable que terminen con una solución real para la distribución.
