- 29,432
- 46
- 8 Ноя 2022
Машина не знала ответа заранее, но помогла шаг за шагом добраться до истины.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Даже крошечная ошибка в ядре Linux может потребовать десятков перезагрузок, если система зависает ещё до появления экрана входа. Линус Торвальдс исправил такой сбой в готовящейся Linux 7.3, а найти причину ему помог ИИ, который писал вспомогательный код для диагностики и разбирал результаты тестов.
Проблема находилась в драйвере графики Intel Xe и могла приводить к зависанию компьютера во время загрузки, когда система переключалась в графический режим. Сбой оказался связан с памятью, которую драйвер резервировал для Compute Command Streamer, а затем ошибочно частично помечал как свободную видеопамять.
Драйвер вычислял границу занятой области, после чего округлял получившийся размер вверх до значения, кратного 128 КБ. В некоторых случаях такой расчёт захватывал память, которая уже использовалась. Исправление оказалось минимальным. Вместо округления вверх код должен был округлять размер вниз.
Сложность заключалась не в исправлении, а в поиске причины. Для диагностики Торвальдс вместе с ИИ постепенно добавлял в ядро код, который собирал дополнительные данные о работе памяти. По его словам, потребовались 24 промежуточных изменения и 18 загрузок ядра, прежде чем удалось точно определить ошибочную операцию округления.
ИИ выполнял вспомогательную работу, анализировал полученные данные и предлагал новые диагностические изменения. Торвальдс при этом контролировал процесс и продолжал проверку даже тогда, когда система предлагала признать проблему нерешаемой. Само исправление ИИ не писал, но сгенерированный им диагностический код помог локализовать дефект.
Исправление уже внесено в код Linux, который готовят к версии 7.3. В описании также указано, что повторный запуск диспетчера входа GDM мог временно обходить сбой, поскольку программа получала другой участок памяти. История показывает практическую роль ИИ в сложной диагностике, где основная работа состоит не в написании итоговой строки кода, а в поиске причины.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Даже крошечная ошибка в ядре Linux может потребовать десятков перезагрузок, если система зависает ещё до появления экрана входа. Линус Торвальдс исправил такой сбой в готовящейся Linux 7.3, а найти причину ему помог ИИ, который писал вспомогательный код для диагностики и разбирал результаты тестов.
Проблема находилась в драйвере графики Intel Xe и могла приводить к зависанию компьютера во время загрузки, когда система переключалась в графический режим. Сбой оказался связан с памятью, которую драйвер резервировал для Compute Command Streamer, а затем ошибочно частично помечал как свободную видеопамять.
Драйвер вычислял границу занятой области, после чего округлял получившийся размер вверх до значения, кратного 128 КБ. В некоторых случаях такой расчёт захватывал память, которая уже использовалась. Исправление оказалось минимальным. Вместо округления вверх код должен был округлять размер вниз.
Сложность заключалась не в исправлении, а в поиске причины. Для диагностики Торвальдс вместе с ИИ постепенно добавлял в ядро код, который собирал дополнительные данные о работе памяти. По его словам, потребовались 24 промежуточных изменения и 18 загрузок ядра, прежде чем удалось точно определить ошибочную операцию округления.
ИИ выполнял вспомогательную работу, анализировал полученные данные и предлагал новые диагностические изменения. Торвальдс при этом контролировал процесс и продолжал проверку даже тогда, когда система предлагала признать проблему нерешаемой. Само исправление ИИ не писал, но сгенерированный им диагностический код помог локализовать дефект.
Исправление уже внесено в код Linux, который готовят к версии 7.3. В описании также указано, что повторный запуск диспетчера входа GDM мог временно обходить сбой, поскольку программа получала другой участок памяти. История показывает практическую роль ИИ в сложной диагностике, где основная работа состоит не в написании итоговой строки кода, а в поиске причины.
- Источник новости
- www.securitylab.ru
