round_up(value, SZ_128K)

którą zmieniono na:

round_down(value, SZ_128K)

Ta różnica ma znaczenie, ponieważ obliczana wartość nie była adresem początku obszaru, lecz limitem wyznaczającym koniec pamięci dostępnej dla alokatora VRAM. Zaokrąglenie limitu w górę sprawiało, że niewielki obszar między rzeczywistą granicą a granicą zaokrągloną wyglądał jak wolna pamięć. W rzeczywistości należał do zarezerwowanych danych CCS. Zaokrąglenie w dół pozostawia alokator po bezpiecznej stronie tej granicy.

Dlaczego błąd niszczył dane GPU

Gdy alokator uznawał pamięć CCS za dostępną, zwykłe alokacje mogły wejść w zarezerwowany obszar i nadpisać metadane wykorzystywane przez GPU. Uszkodzeniu ulegały między innymi dane związane z tablicami stron, co prowadziło do artefaktów na ekranie oraz niekończących się restartów menedżera logowania GDM na sprzęcie Battlemage G21.

Nie był to więc wyłącznie błąd arytmetyczny. Problem wynikał z pomylenia znaczenia wartości: kod traktował ją tak, jakby wskazywała adres początkowy wymagający wyrównania, choć w rzeczywistości oznaczała limit, za którym kończyła się użyteczna pamięć. Dlatego końcowa poprawka była tak mała, a jednocześnie tak trudna do znalezienia.

24 poprawki i 18 uruchomień jądra

Torvalds i asystent AI dodawali oraz modyfikowali celowaną instrumentację, śledzili obliczenia wykonywane przez sterownik i porównywali pozycję CCS zgłaszaną przez sprzęt z granicą przekazywaną alokatorowi VRAM. Dopiero po 24 wersjach poprawek debugujących i 18 cyklach ponownego uruchamiania oraz testowania stało się jasne, że problemem był niewłaściwy kierunek zaokrąglania.

Kolejne uruchomienia były istotne, ponieważ awaria ujawniała się na poziomie sprzętu i systemu graficznego, a nie tylko jako podejrzanie wyglądający fragment kodu. Każdy eksperyment pomagał odróżnić błędy alokacji pamięci od innych możliwych przyczyn problemów z obrazem.

AI przyspieszyła pracę, ale nie prowadziła śledztwa

Torvalds wykorzystywał asystenta jako interaktywnego partnera do debugowania. Narzędzie pomagało proponować instrumentację, prześledzić ścieżki wykonywania kodu i analizować wyniki kolejnych prób. Dzięki temu ograniczono ilość powtarzalnej pracy potrzebnej do sprawdzania hipotez.

AI nie była jednak wiarygodnym autorytetem. Torvalds relacjonował, że kilka razy uznała problem za niemożliwy lub nierozwiązywalny i sugerowała, by zakończyć pracę oraz przygotować raport. To on wybierał następne eksperymenty, odrzucał błędne interpretacje i rozumiał, co dana wartość oznacza w modelu pamięci alokatora.

To właśnie podział obowiązków jest najważniejszym elementem tej historii. AI generowała możliwości i wykonywała czynności techniczne, natomiast ekspert zapewniał kontekst, uporczywość, testy możliwe do obalenia oraz ostateczną ocenę poprawki.

Poprawka trafiła do głównego drzewa, ale wersje stabilne pozostają niewiadomą

Linus Torvalds sam przygotował i zatwierdził poprawkę sterownika Intel Xe w głównym, rozwijanym jądrze Linuksa. Z dostępnych informacji wynika, że zmiana miała trafić także do utrzymywanych stabilnych gałęzi w ramach standardowego procesu backportowania, czyli przenoszenia poprawki do starszych wydań. Źródła nie pozwalają jednak wiarygodnie wskazać konkretnych wersji ani dat ich publikacji.

Dlatego nie należy jeszcze przypisywać poprawki określonym wydaniom stabilnym wyłącznie na podstawie dostępnych doniesień. Użytkownicy dotkniętego problemem sprzętu powinni sprawdzać komunikaty swojej dystrybucji lub opiekunów jądra, aby potwierdzić, czy dana kompilacja zawiera zmianę.

Lekcja dla programistów korzystających z AI

Ta historia nie jest bezwarunkową pochwałą kodu generowanego przez AI. Pokazuje raczej węższy i lepiej uzasadniony model pracy: ekspert może użyć sztucznej inteligencji do przyspieszenia trudnej pętli debugowania, ale nadal odpowiada za hipotezę, projekt testów, przegląd zmian i końcową poprawkę.

To zupełnie co innego niż wysyłanie opiekunom jądra nieprzetestowanych, niezamówionych poprawek lub raportów o lukach wygenerowanych przez model językowy. Deweloperzy Linuksa mówili o „natarciu” takich zgłoszeń, a opiekunowie podsystemów staging i sieci opisywali rosnącą frustrację z powodu poprawek o niskiej wartości lub niezrozumianych przez ich autorów.

Często powtarzaną informację o wzroście liczby zgłoszeń o 2700 proc. należy traktować ostrożnie. Dostępne materiały nie wyjaśniają w sposób wystarczająco wiarygodny metody pomiaru, przedziału czasowego ani dokładnej kategorii, której dotyczy ta liczba. Lepiej udokumentowany wniosek jest bardziej ogólny: AI obniżyła koszt tworzenia kodu i raportów, ale czas potrzebny na ich sprawdzenie i posegregowanie nadal muszą poświęcać ludzie.

Torvalds podkreślał też, że Linux nie jest z założenia projektem wrogo nastawionym do AI, zwłaszcza gdy narzędzia tego typu pomagają w przeglądzie kodu. Sesja debugowania Intel Xe pokazuje jednak wyraźną granicę: AI może być użyteczna w zdyscyplinowanym procesie inżynieryjnym, lecz nie zastąpi znajomości podsystemu, powtarzalnych testów ani człowieka, który bierze odpowiedzialność za rezultat.

Końcowa poprawka miała jedną linijkę. Prawdziwym osiągnięciem było ustalenie, którą linijkę zmienić — i nieprzerywanie poszukiwań, gdy asystent uznał, że rozwiązania nie da się znaleźć.

round_up(value, SZ_128K)

którą zmieniono na:

round_down(value, SZ_128K)

Ta różnica ma znaczenie, ponieważ obliczana wartość nie była adresem początku obszaru, lecz limitem wyznaczającym koniec pamięci dostępnej dla alokatora VRAM. Zaokrąglenie limitu w górę sprawiało, że niewielki obszar między rzeczywistą granicą a granicą zaokrągloną wyglądał jak wolna pamięć. W rzeczywistości należał do zarezerwowanych danych CCS. Zaokrąglenie w dół pozostawia alokator po bezpiecznej stronie tej granicy.

Dlaczego błąd niszczył dane GPU

Gdy alokator uznawał pamięć CCS za dostępną, zwykłe alokacje mogły wejść w zarezerwowany obszar i nadpisać metadane wykorzystywane przez GPU. Uszkodzeniu ulegały między innymi dane związane z tablicami stron, co prowadziło do artefaktów na ekranie oraz niekończących się restartów menedżera logowania GDM na sprzęcie Battlemage G21.

Nie był to więc wyłącznie błąd arytmetyczny. Problem wynikał z pomylenia znaczenia wartości: kod traktował ją tak, jakby wskazywała adres początkowy wymagający wyrównania, choć w rzeczywistości oznaczała limit, za którym kończyła się użyteczna pamięć. Dlatego końcowa poprawka była tak mała, a jednocześnie tak trudna do znalezienia.

24 poprawki i 18 uruchomień jądra

Torvalds i asystent AI dodawali oraz modyfikowali celowaną instrumentację, śledzili obliczenia wykonywane przez sterownik i porównywali pozycję CCS zgłaszaną przez sprzęt z granicą przekazywaną alokatorowi VRAM. Dopiero po 24 wersjach poprawek debugujących i 18 cyklach ponownego uruchamiania oraz testowania stało się jasne, że problemem był niewłaściwy kierunek zaokrąglania.

Kolejne uruchomienia były istotne, ponieważ awaria ujawniała się na poziomie sprzętu i systemu graficznego, a nie tylko jako podejrzanie wyglądający fragment kodu. Każdy eksperyment pomagał odróżnić błędy alokacji pamięci od innych możliwych przyczyn problemów z obrazem.

AI przyspieszyła pracę, ale nie prowadziła śledztwa

Torvalds wykorzystywał asystenta jako interaktywnego partnera do debugowania. Narzędzie pomagało proponować instrumentację, prześledzić ścieżki wykonywania kodu i analizować wyniki kolejnych prób. Dzięki temu ograniczono ilość powtarzalnej pracy potrzebnej do sprawdzania hipotez.

AI nie była jednak wiarygodnym autorytetem. Torvalds relacjonował, że kilka razy uznała problem za niemożliwy lub nierozwiązywalny i sugerowała, by zakończyć pracę oraz przygotować raport. To on wybierał następne eksperymenty, odrzucał błędne interpretacje i rozumiał, co dana wartość oznacza w modelu pamięci alokatora.

To właśnie podział obowiązków jest najważniejszym elementem tej historii. AI generowała możliwości i wykonywała czynności techniczne, natomiast ekspert zapewniał kontekst, uporczywość, testy możliwe do obalenia oraz ostateczną ocenę poprawki.

Poprawka trafiła do głównego drzewa, ale wersje stabilne pozostają niewiadomą

Linus Torvalds sam przygotował i zatwierdził poprawkę sterownika Intel Xe w głównym, rozwijanym jądrze Linuksa. Z dostępnych informacji wynika, że zmiana miała trafić także do utrzymywanych stabilnych gałęzi w ramach standardowego procesu backportowania, czyli przenoszenia poprawki do starszych wydań. Źródła nie pozwalają jednak wiarygodnie wskazać konkretnych wersji ani dat ich publikacji.

Dlatego nie należy jeszcze przypisywać poprawki określonym wydaniom stabilnym wyłącznie na podstawie dostępnych doniesień. Użytkownicy dotkniętego problemem sprzętu powinni sprawdzać komunikaty swojej dystrybucji lub opiekunów jądra, aby potwierdzić, czy dana kompilacja zawiera zmianę.

Lekcja dla programistów korzystających z AI

Ta historia nie jest bezwarunkową pochwałą kodu generowanego przez AI. Pokazuje raczej węższy i lepiej uzasadniony model pracy: ekspert może użyć sztucznej inteligencji do przyspieszenia trudnej pętli debugowania, ale nadal odpowiada za hipotezę, projekt testów, przegląd zmian i końcową poprawkę.

To zupełnie co innego niż wysyłanie opiekunom jądra nieprzetestowanych, niezamówionych poprawek lub raportów o lukach wygenerowanych przez model językowy. Deweloperzy Linuksa mówili o „natarciu” takich zgłoszeń, a opiekunowie podsystemów staging i sieci opisywali rosnącą frustrację z powodu poprawek o niskiej wartości lub niezrozumianych przez ich autorów.

Często powtarzaną informację o wzroście liczby zgłoszeń o 2700 proc. należy traktować ostrożnie. Dostępne materiały nie wyjaśniają w sposób wystarczająco wiarygodny metody pomiaru, przedziału czasowego ani dokładnej kategorii, której dotyczy ta liczba. Lepiej udokumentowany wniosek jest bardziej ogólny: AI obniżyła koszt tworzenia kodu i raportów, ale czas potrzebny na ich sprawdzenie i posegregowanie nadal muszą poświęcać ludzie.

Torvalds podkreślał też, że Linux nie jest z założenia projektem wrogo nastawionym do AI, zwłaszcza gdy narzędzia tego typu pomagają w przeglądzie kodu. Sesja debugowania Intel Xe pokazuje jednak wyraźną granicę: AI może być użyteczna w zdyscyplinowanym procesie inżynieryjnym, lecz nie zastąpi znajomości podsystemu, powtarzalnych testów ani człowieka, który bierze odpowiedzialność za rezultat.

Końcowa poprawka miała jedną linijkę. Prawdziwym osiągnięciem było ustalenie, którą linijkę zmienić — i nieprzerywanie poszukiwań, gdy asystent uznał, że rozwiązania nie da się znaleźć.