Jak zrozumieć panic full log w iPhone i iPad

panic log baner

iPhone Kernel Panic Full Log, bo tak brzmi pełna tego nazwa (oraz obligatoryjnie dla iPada lub Mac’a), to zapis stanu jądra i dziennik awarii w systemie twojego urządzenia. Nie jest to jednak pełne repozytorium problemu. Te ciągle są tworzone przez inżynierów kodu w Cupertino a co ważniejsze, ciągle się zmienia, zależnie od potrzeb badanych zasobów sprzętowych.

panic full lub crash log to dokumentacja zdarzeń w systemach unix’owych (twój IOS to Unix basedOS)

Przez analogie do moich doświadczeń z maszynami unixowymi problem z czytelnością Panic Full Log przestał być przerażający. Wszystko zaczęło się układać dopiero, kiedy skojarzyłem wspólne cechy, niedostrzegalne wcześniej z powodu zakodowania istotnych informacji. Na teraz, wydaje mi się, że mam zgodność do wersji 16 i chyba wiem gdzie patrzeć, kiedy pojawi się i 17’ta.

Panic Full Log (lub crash.log – zależnie od urządzenia) pojawia się zawsze, kiedy jądro systemu ma problem sprzętowy z funkcją sterownika, strukturą danych albo potokiem przychodzącym z czujników. W wielu przypadkach można się bez tego obejść, jednak od jakiegoś czasu (iOS 14.5) jest to wystarczający powód by w kilku przypadkach uruchomić procedurę ponownego startu (… wydaje mi się, że ma to związek ekonomiczny).

Lokalizacja nie zmieniła się od wielu wydań, przejdź do ustawienia — >> prywatność i ochrona — >> analizy i udoskonalenia — >> dane analiz. W katalogu danych znajdą się wszystkie raporty analityczne, Feedback’i pomiary i inne, posegregowane alfabetycznie. Znajdź literę ” P ” – Panic.Log lub Panic.Full zakończone numerami (data, godzina).

Czytanie zapisu dziennika jest proste choć poszczególne sekcje, zależnie od wersji mogą zmieniać swoje położenie. Nie powinno być trudności ze zlokalizowaniem poszczególnych miejsc. W przypadku wątpliwości napisz email, postaram się pomóc. Zaczyna się od umiejscowienia raportu w czasie. Potem przedstawienie warunków brzegowych urządzenia i wskazanie miejsca problemu. Istotne robi się od sekcji „panicString”. Znajdziesz tam dość czytelny opis problemu z jego sygnaturą pamięci operacyjnej. Poniżej, to już tylko zakodowane informacje debuggera projektowego, zrzut pamięci i inne, istotne dla inżynierów produktu szczegóły. W pliku poniżej, dwa przykłady: z zegarka (to też pro’unixOS) po lewej i telefonu po prawej. Zaznaczone sekcje rozwiążą wątpliwości.

Na marginesie zwrócę uwagę na dwie rzeczy – sekcje są podzielone zgodnie z „informacją bitową” (dla programistów Swift) oraz zastrzeżenie, że zapisy takiego raportu należy (w tej sekcji) traktować jako wskazówkę, nic więcej. Budowa raportu i jego kod zmienia się razem z wydaniem wersji systemu.

Rodzaje Panic Full Log i ich rozszyfrowane wskazania

Watchdog Timeout Thermalmonitord Missing Sensor (brak czujnika)

proces systemowy Watchdog ma zaprogramowany cykl badania danych zewnętrznych czujników. Cykl jest cykliczny, jak nazwa wskazuje i ma wartość 180 sekund. Jeśli interwał pomiarowy nie zostanie przerwany przez napływające dane (potwierdzone), system rozpocznie awaryjne uruchomienie, licząc że ponowny start systemu i bieżące uruchomienie czujnika rozwiąże problem. By odnaleźć brakujący sygnał z czujnika analizuj napływające dane z Panic.Log. ( DOTYCZY wyłącznie modeli 7-12pro/Max )

PRSo – czujnik napięcia portu ładującego (room=dock)
Mic1 – czujnik (funkcja nieznana) dolnej taśmy łączącej (room=dock_flex)
Mic2 – czujnik (funkcja nieznana) górnej taśmy łączącej (room=power_flex/strobe)
TG0V – czujnik napięcia baterii (room=battery)
TG0B – czujnik temperatury baterii (room=battery)
TT0D-TT9D – czujnik sterownika ekranu (występuje tylko w tabletach)

Watchdog Timeout No Check In (brak meldunku)

Proces Timeout sprawdza ogólną funkcjonalność systemu. Jeśli czas „między zameldowaniami „sub-check” przekroczy wartość maksymalną, urządzenie uruchomi się ponownie, aby spróbować to naprawić. Łatwe do namierzenia, jeśli w instrukcji Springboardlogdwifid lub Thermalmonitord  nie występuje fizyczna lokalizacja czujnika. Zakładam, że w takim przypadku chodzi o komponent softwarowy. Szczególnie widoczny w pierwszych wydaniach wersji 16.0. Od wersji 16.2 nie odnotowałem żadnego przypadku (wnioski?)
( DOTYCZY wyłącznie modeli 7-12pro/Max )

i2c (i2c0-5) Panic Full log

protokół komunikacyjny typu master – slaves. Więcej o tym będzie za jakiś czas, w dziale teoretycznym blogu studionarpaw.pl z uwagi na spory zakres zagadnienia. Na teraz niech wystarczy to, że urządzeniem MASTER w tej architekturze zawsze jest procesor główny a odbiornikami (SLAVE) sterowniki obwodowe i podukładowe. Jeśli instrukcja nie dociera lub brakuje sumy kontrolnej sygnału, musi dziać się coś złego fizycznie „na trasie”.

AOP Panic Full log

AOP to cały podzbiór typów funkcji. Informacje o tym, do czego konkretnie odnosi się AOP, nie są powszechnie znane. Przedarły się jednak informacje, że cały segment (APsoc) procesora jest przeznaczona do nadzorowania funkcji AOP.

AOP NMI POWER (Non-Maskable Interrupt)

Rodzaj przerwania IRQ o nadanych uprawnieniach nadzwyczajnych. Posiada pierwszeństwo w udziałach pamięci i prawo do przerywania transmisji o niższym priorytecie. Wszystko wskazuje na to, że jest związana z mechanizmem AP.SEP „Secure Enclave”, zespołem przednich czujników Face.ID i przedniej kamery.

ANS2 Recoverable Panic Full log

Apple NAND Storage v.2 – kontroler przechowywania danych NORD lub NAND. Dziennik może wskazywać na uszkodzenie samego układu. Przykład zwarcia lub zakłócenia harmonicznego sygnału sterującego/ logicznego.

AppleSoc: Hot Hot Hot

komunikat typu alarm. Informuje o krytycznym odczycie temperatury z wewnętrznego mechanizmu autokontroli procesora głównego i pamięci RAM. Kiedy go zobaczysz, prawdopodobnie jest już za późno.

SEP.Rom Panic Full log

The Secure Enclave Processor (AP.SEP) to wydzielona warstwa procesora do przechowywania danych ultra-chronionych. Wskazuje na uszkodzenia w przestrzeni transmisji lub warstwy fizycznej urządzeń podukładu „Secure”. W skład podukładu wchodzą procesor główny, urządzenia zespołu Face.ID/Touch.ID, NAND, Baseband, Stockholm i eeprom.

SMC Assertion Failed

SMC to znane urządzenie wszystkim technikom Mac i MacBook. W iPad i iPhone urządzenie SMC także występuje, jednak od modelu 11, wkomponowane do układowego PMU, w późniejszych przeniesione do CPU. Ten typ błędu zazwyczaj ma string BSC FAILURE. W modelach od 13 błąd powoduje restarty systemu w interwale 180 sekund (wydaje się być nową wersją Watchdog). Zawsze występuje z parametrem tablicy czujników – jak niżej: ( DOTYCZY wyłącznie modeli od 13 )

0x800 – adres dotyczy zespołu portu ładowania
0x1000 – adres dotyczy sterownika taśmy Power/Flash
0x4000 – adres dotyczy wbudowanego sterownika baterii

Undefined Kernel Instruction (niezidentyfikowana funkcja jądra)

Kernel jest tym, na co wskazuje nazwa (serce systemu). Niezidentyfikowane instrukcje, funkcje i tablice to stały fragment zabawy inżyniera systemu. Jeśli napotkasz ten błąd, najprawdopodobniej jest związany z samym systemem lub niekompatybilną aplikacją (co już się zdarzało).

Na koniec, jeszcze w kilku słowach o robotach (aplikacjach do interpretowania). Jest ich kilka w użyciu. W mojej ocenie, najbardziej popularny wskazuje ciągle tą samą grupę błędów (choć może mam za mało doświadczenia by to ocenić). Zawsze winien ma być port ładowania i taśma Power. W innym, popularnym urządzeniu (3uT) liczona jest tylko liczba logów. Informacja także jest taka sama: „odwiedź warsztat naprawczy”.

Mam nadzieję, że nieco przybliżyłem problem. Jeśli wpłynie to pozytywnie na jakość naprawianych przez Ciebie (czytelniku) urządzeń, zostaw komentarz i pochwal się tym. Będzie mi niezmiernie miło, że moja praca jest potrzebna.