Bir önceki bölümün sonunda ASUS RP-N12'ye bir çeşit kara kutu takmıştık.
Cihazın kendi syslog'u RAM üzerinde tutulduğu için RP-N12 kilitlendiğinde veya yeniden başladığında asıl görmek istediğimiz kayıtların kaybolma ihtimali vardı. Bu nedenle Windows bilgisayarda UDP/514 dinleyen küçük bir Python programı kurduk. RP-N12 bütün kernel ve sistem mesajlarını ağ üzerinden bu bilgisayara göndermeye başladı.
Task Scheduler sayesinde logger Windows açıldığında otomatik başlıyor, bilgisayarın kendi zaman damgasını da her satıra ekliyordu.
Sonra yapılacak pek bir şey kalmamıştı.
RP-N12 çalışmaya devam edecekti.
Biz de bozulmasını bekleyecektik.
Kara kutunun ilk ciddi kaydı için fazla beklemek gerekmedi.
04:36 — Kernel Bellek Ayıramıyor
18 Eylül 2026, saat 04:36:45.
Syslog dosyasına bir anda uzun bir kernel dump'ı düşmeye başladı.
İçindeki en önemli satırlardan biri şuydu:
SLUB: Unable to allocate memory on node -1 (gfp=0x20)
cache: kmalloc-8192
object size: 8192
buffer size: 8192
default order: 3
min order: 1
node 0:
slabs: 95
objs: 269
free: 0
Ardından kernel mevcut belleğin durumunu da döktü:
free:50
slab_reclaimable:133
slab_unreclaimable:1435
Normal free:200kB
min:508kB
low:632kB
high:760kB
slab_reclaimable:532kB
slab_unreclaimable:5740kB
Ve buddy allocator'ın elindeki fiziksel sayfalar:
Normal:
26*4kB
0*8kB
4*16kB
1*32kB
0*64kB
0*128kB
0*256kB
0*512kB
0*1024kB
0*2048kB
0*4096kB
= 200kB
Bu artık RP-N12'nin “arada bir saçmalıyor” seviyesinde bir belirti değildi.
Linux kernel gerçekten bir bellek tahsis isteğini karşılayamamıştı.
Fakat burada hemen “RAM bitti” veya “memory leak bulduk” demek de doğru değildi.
Olay biraz daha ilginçti.
8 KB Ayıramayan Linux
Hatanın merkezinde şu cache vardı:
kmalloc-8192
Linux kernel'deki kmalloc() fiziksel kernel belleğinden küçük nesneler ayırmak için kullanılan temel mekanizmalardan biri.
kmalloc-8192 ise 8192 byte, yani 8 KiB büyüklüğündeki nesneler için kullanılan slab cache.
Kernel o anda 8 KiB'lık bir tahsis yapmaya çalışmış ve başarısız olmuştu.
8 KiB bugün kullandığımız bilgisayarlar açısından komik derecede küçük bir miktar.
Ama RP-N12'nin dünyasında durum biraz farklı.
Kernel dump'ının ilerleyen satırlarında şunu görüyoruz:
4096 pages RAM
646 pages reserved
MIPS kernel'imizde sayfa boyutu 4096 byte.
Dolayısıyla fiziksel RAM:
4096 × 4096
= 16,777,216 byte
= 16 MiB
RP-N12'nin bütün fiziksel belleği yalnızca 16 MiB.
Bunun da tamamını Linux kullanamıyor.
Canlı sistemde /proc/meminfo:
MemTotal: 13864 kB
gösteriyordu.
Yani kernel, ayrılmış fiziksel bölgeler ve diğer düşük seviye ihtiyaçlardan sonra Linux'un hesapladığı kullanılabilir RAM yaklaşık 13.5 MiB.
Ve bu küçücük alanın içinde Linux kernel, Wi-Fi sürücüsü, Ethernet, network stack, web arayüzü, dnsmasq, watchdog, syslog, telnet ve geri kalan her şey birlikte yaşıyor.
MemFree Neden Tek Başına Yeterli Değil?
Olaydan önce yaptığımız ölçümlerde şuna benzer değerler görüyorduk:
MemTotal: 13864 kB
MemFree: 1244 kB
Buffers: 1184 kB
Cached: 2556 kB
Slab: 4892 kB
SReclaimable: 532 kB
SUnreclaim: 4360 kB
İlk bakışta:
“Sadece 1.2 MB RAM kalmış.”
demek mümkün.
Ama Linux belleği böyle okunmuyor.
Boş RAM'in bir kısmını cache olarak kullanmak Linux için normal. Gerektiğinde bazı cache'ler geri alınabilir.
Bu nedenle bizi asıl ilgilendiren başka bir alan vardı:
Slab
Slab allocator kernel'in sürekli oluşturup yok ettiği küçük nesneleri verimli biçimde yönetmek için kullandığı bellek sistemi.
Örneğin dosya sistemi yapıları, network yapıları, socket'ler, çeşitli kernel objeleri ve kmalloc cache'leri burada bulunabiliyor.
Slab belleğinin iki önemli kısmı var:
SReclaimable
SUnreclaim
SReclaimable, kernel'in gerektiğinde geri kazanabileceği slab belleği.
SUnreclaim ise kolayca geri alınamayan aktif kernel nesneleri.
Bizim ilk baseline ölçümlerimiz:
SUnreclaim: 4332 kB
SUnreclaim: 4360 kB
civarındaydı.
Bellek tahsis hatası anında kernel'in verdiği değer ise:
slab_unreclaimable:5740kB
oldu.
Yaklaşık 1.4 MiB artış.
16 MiB fiziksel RAM'li bir sistem için 1.4 MiB küçük bir değişiklik değil.
Üstelik hata anında toplam unreclaimable slab yaklaşık 5.7 MiB olmuştu.
Fiziksel RAM'in üçte birinden fazlası.
Memory Leak mi Bulduk?
Henüz hayır.
Bu noktada ilk güçlü şüphemiz doğal olarak kernel veya Wi-Fi driver tarafında bir slab leak olmasıydı.
Fakat birkaç saat sonra tekrar /proc/meminfo aldığımızda:
MemFree: 948 kB
Buffers: 1172 kB
Cached: 2760 kB
Slab: 5016 kB
SReclaimable: 544 kB
SUnreclaim: 4472 kB
gördük.
Yani hata anında:
5740 kB
olan SUnreclaim, daha sonra:
4472 kB
seviyesine geri inmişti.
Bu önemli.
Eğer bütün artış kalıcı bir leak olsaydı belleğin geri dönmemesini beklerdik.
Dolayısıyla şu aşamada daha doğru ifade:
RP-N12 ciddi bir kernel memory-pressure olayı yaşadı. Unreclaimable slab belirgin biçimde yükseldi ve kernel bir bellek tahsisini gerçekleştiremedi. Ancak elimizde henüz monoton biçimde büyüyen kalıcı bir memory leak kanıtı yok.
Fragmentation da olayın bir parçası olabilir.
RAM Var Ama Uygun RAM Yok
Kernel dump'ındaki en öğretici satırlardan biri buydu:
Normal: 26*4kB 0*8kB 4*16kB 1*32kB ...
Burada Linux buddy allocator'ın o anda elindeki serbest fiziksel blokları görüyoruz.
Toplam:
200 kB
serbest alan bulunuyor.
Ama dağılıma dikkat:
26 × 4 KB
0 × 8 KB
4 × 16 KB
1 × 32 KB
Bellek yalnızca toplam miktardan ibaret değil.
Kernel bazı tahsislerde belirli büyüklükte fiziksel olarak uygun ve contiguous sayfalara ihtiyaç duyuyor.
Logda ayrıca:
page allocation failure. order:1
mesajı da bulunuyordu.
4 KiB sayfalı sistemde order:1 iki ardışık sayfa, yani 8 KiB'lık fiziksel blok anlamına gelir.
Tam da kmalloc-8192 olayımızın büyüklüğü.
Bu yüzden:
“200 KB boş RAM vardı; 8 KB'ı nasıl ayıramadı?”
sorusu ilk bakışta mantıklı görünse de doğru soru değil.
Doğru soru:
“İstenen biçimde uygun fiziksel sayfalar mevcut muydu?”
Kernel'in cevabı o anda hayırdı.
16 MB RAM'den Nasıl Gigabaytlarca Veri Geçiyor?
Bu noktada başka bir soru ortaya çıktı.
RP-N12'nin yalnızca 16 MiB RAM'i varsa televizyona saatlerce video nasıl taşıyabiliyor?
Canlı /proc/net/dev sayacı bize Ethernet tarafında şunu göstermişti:
eth2 RX bytes:
2427196843
Yaklaşık 2.43 GB veri yalnızca o uptime sırasında Ethernet'ten geçmişti.
Aynı zamanda Wi-Fi tarafında:
ra0 TX bytes:
2368736948
yaklaşık 2.37 GB gönderilmişti.
Bu değerler AP'nin yaptığı işi çok güzel gösteriyor:
Ethernet
|
| ~2.4 GB
v
RP-N12
|
| ~2.37 GB
v
Wi-Fi
Peki 16 MB RAM'den 2.4 GB nasıl geçiyor?
Çünkü RAM bir depo değil.
Bir çalışma alanı.
Paket Fabrikası
Klasik Ethernet MTU'su çoğu ağda:
1500 byte
civarında.
Bir byte 8 bit olduğuna göre:
1500 × 8 = 12000 bit
Örneğin 20 Mbit/s trafik için kaba hesap:
20,000,000 / 12,000
≈ 1667 paket/saniye
Gerçek TCP/IP/Ethernet hesabında header'lar, Wi-Fi overhead'i, ACK'ler, retransmission, aggregation ve başka ayrıntılar var; bu yalnızca ölçeği görmek için kaba bir hesap.
Ama temel fikir değişmiyor.
Paket geliyor.
Bir RX buffer'a giriyor.
Network stack paketi işliyor.
Bridge paketi Wi-Fi arayüzüne yönlendiriyor.
TX descriptor hazırlanıyor.
Wi-Fi donanımı paketi gönderiyor.
Buffer serbest bırakılıyor veya tekrar kullanılıyor.
Sonra aynı bellek başka paket için kullanılıyor.
+-------- RAM --------+
| |
Ethernet -> RX -> bridge -> TX -+-> Wi-Fi
| |
+---- buffer reuse ---+
RP-N12'nin RAM'i videonun tamamını saklamıyor.
Verinin çok küçük bir bölümünü herhangi bir anda taşıyor.
Bir otoyoldan günde on bin otomobil geçmesi için otoyolun aynı anda on bin otomobili tutabilmesi gerekmediği gibi.
Buffer Gerçekten Büyümeye Başlarsa?
Asıl sorun giriş ve çıkış hızları birbirinden ayrıldığında oluşuyor.
Kabaca:
Queue growth = Rin - Rout
Örneğin Ethernet tarafından:
80 Mbit/s
geliyor fakat Wi-Fi o anda yalnızca:
30 Mbit/s
aktarabiliyorsa fark:
50 Mbit/s
olur.
Bu:
6.25 MB/s
buffer büyüme hızı demek.
Sadece 100 ms böyle devam etse:
625 KB
queue oluşabilir.
16 MiB RAM'li bir cihazda bu artık ihmal edilebilir bir miktar değil.
Gerçekte network stack, queue limitleri, packet drop ve TCP congestion control gibi mekanizmalar bu büyümenin sonsuza kadar sürmesine izin vermez.
Ama bu hesap küçük RAM'li bir AP'de network buffer yönetiminin neden önemli olduğunu gösteriyor.
Netflix 4K Çalışıyor Ama Remote Desktop Sürünüyor
RP-N12 üzerinde yaptığımız başka bir deney de bu noktada anlam kazandı.
LG OLED televizyon üzerinden bilgisayara Remote Desktop bağlandığımda performans son derece kötüydü.
Fakat aynı televizyon aynı AP üzerinden yüksek kaliteli video streaming yapabiliyordu.
İlk bakışta:
“4K video çalışıyorsa masaüstü neden çalışmıyor?”
sorusu oldukça mantıklı.
Fakat ağ açısından bu iki uygulama çok farklı.
Streaming uygulaması gelecekte kullanacağı veriyi önceden indirebilir.
Kabaca:
NETWORK ------------> BUFFER -----------> VIDEO
###########
^
playback
Wi-Fi 200 ms kötüleşirse televizyon buffer'daki videoyu oynatmaya devam eder.
Kullanıcı hiçbir şey fark etmeyebilir.
Remote Desktop'ta ise gelecek önceden indirilemez.
Mouse'u hareket ettirmeden PC gelecekte hangi ekranı üretmesi gerektiğini bilmiyor.
Akış şöyle:
INPUT
|
v
TV
|
v
Wi-Fi
|
v
PC
|
+-- masaüstünü değiştir
+-- görüntüyü üret
+-- encode et
|
v
NETWORK
|
v
Wi-Fi
|
v
TV
|
+-- decode
+-- display
Bu zincirdeki her gecikme kullanıcının parmağı ile ekrandaki tepki arasına ekleniyor.
Bu nedenle streaming için esas sorunlardan biri yeterli ortalama throughput iken interaktif Remote Desktop için:
latency, jitter, retransmission ve packet loss
çok daha görünür hale geliyor.
Dolayısıyla paradoksal görünen şu durum gayet mümkün:
20 Mbit/s'lik buffered bir video akışı, 5 Mbit/s'lik interaktif Remote Desktop oturumundan kullanıcı açısından çok daha sorunsuz olabilir.
Bilgisayar grafikleri tarafından düşünürsek bunu şöyle hayal etmek mümkün:
Streaming, önceden hazırlanmış karelerin oynatılmasına benziyor.
Remote Desktop ise her input'tan sonra yeni görüntünün gerçek zamanlı üretilmesini gerektiriyor.
Bu yüzden yeni bir access point'ten beklediğimiz kazanç yalnızca “daha fazla Mbps” olmayacak.
Asıl fark:
daha düşük latency
daha düşük jitter
daha az retransmission
daha verimli airtime
daha güçlü CPU/RAM
tarafında olacak.
16:12 — Kara Kutu Tekrar Konuşuyor
Memory allocation failure'dan yaklaşık on bir buçuk saat sonra syslog'a iki yeni kernel mesajı düştü.
2026-09-18 16:12:34.678
kernel: 0x60330030=0x92e8ff
2026-09-18 16:12:34.685
kernel: 0x6033001C=0xffff
Hepsi bu.
Öncesinde açıklayıcı bir hata mesajı yok.
Sonrasında stack trace yok.
İki register adresi.
İki hexadecimal değer.
İlk bakışta bunların hangi subsystem'e ait olduğunu bile bilmiyorduk.
Bu noktada RP-N12'nin firmware'ine inmeye karar verdik.
ASUS Hâlâ Kaynak Kodu Tutuyormuş
RP-N12 için ASUS'un yayınladığı GPL source paketini bulduk.
Paket firmware 1.0.1.0g dönemine ait.
Bizim cihazdaki daha yeni firmware'in birebir source'u değil; dolayısıyla bunu önemli bir sınırlama olarak akılda tutmak gerekiyor.
Arşiv açıldığında karşımıza klasik bir embedded Linux SDK ağacı çıktı:
linux-2.6.36.x/
user/
vendors/
tools/
lib/
config/
prebuild_romfs/
Kernel:
Linux 2.6.36
Board configuration ise kullandığımız platformu açıkça gösteriyordu:
CONFIG_RALINK_MT7628=y
CONFIG_MT7628_ASIC=y
CONFIG_FIRST_IF_MT7628=y
CONFIG_RT_FIRST_CARD=7628
CONFIG_RT2880_DRAM_16M=y
CONFIG_RALINK_RAM_SIZE=16
Böylece runtime'da hesapladığımız 16 MiB RAM, ASUS'un build configuration'ıyla da doğrulanmış oldu.
Fakat asıl aradığımız şey:
0x60330030
0x6033001C
idi.
Kaynak kod içerisinde bu adresler doğrudan bulunamadı.
Sebebi kısa süre sonra ortaya çıktı.
Wi-Fi Driver'ın Source'u Yok
ASUS GPL paketinde Ralink/MediaTek Wi-Fi driver'ının kaynak kodu bulunmuyordu.
Build sistemi ayrı bir dizine referans veriyordu:
../NonGPL/drivers
Dağıtılan pakette bu dizin yoktu.
Fakat firmware'in hazırlanabilmesi için önceden derlenmiş kernel modülü bırakılmıştı:
prebuild_romfs/usr/lib/mt_wifi.ko
Yaklaşık 1.6 MB'lık MIPS kernel modülü.
Ve şansımıza tamamen strip edilmemişti.
İçerisinde hâlâ:
function symbols
debug strings
relocations
bulunuyordu.
Dolayısıyla source code yoktu ama binary bize hâlâ oldukça fazla şey anlatabilirdi.
mt_wifi.ko'yu Disassemble Etmek
İlk olarak binary'nin string tablosunda gizemli adresleri aradık.
Ve birebir bulduk:
0x60330030=0x%x
0x6033001C=0x%x
Bu önemli bir dönüm noktasıydı.
Artık syslog'daki iki satırın:
MediaTek/Ralink Wi-Fi driver'ı mt_wifi.ko
tarafından üretildiğini biliyorduk.
ELF relocation bilgileri sayesinde bu stringleri kullanan fonksiyonu da bulabildik:
SetTxRxCr_Proc()
Fonksiyon bir string parametre alıyor.
İlgili kod yolu:
SetTxRxCr_Proc(pAd, "0")
şeklinde çağrılıyor.
Fonksiyon "0" modunda çalıştığında iki register'ı okuyup kernel loguna yazıyor:
0x60330030
0x6033001C
Tam olarak kara kutunun kaydettiği iki satır.
Peki SetTxRxCr_Proc() Neden Çağrılmış?
Bir sonraki adım çağıran fonksiyonu bulmaktı.
Relocation/call ilişkisini geriye doğru takip ettiğimizde karşımıza şu çıktı:
APCheckBcnQHandler()
İsim oldukça açıklayıcı.
Bcn, driver içerisinde beacon için kullanılan kısaltma.
Wi-Fi access point'ler düzenli aralıklarla beacon frame yayınlar. Bu frame'ler ağın varlığını, SSID'yi ve çeşitli kablosuz ağ parametrelerini duyuran temel 802.11 management frame'leridir.
Aynı binary içinde ilgili kod çevresinde şu debug stringleri bulunuyordu:
bcn_flush too long!
flush all stuck bcn too long!!
Ayrıca:
DumpBcnQMessage
PSEWatchDog
MonitorTxBcnRxPse
gibi semboller de aynı driver'da bulunuyor.
Artık iki hexadecimal register satırı çok daha anlamlı hale gelmişti.
Bunlar rastgele debug çıktıları değildi.
Access point'in beacon/TX queue sağlık kontrolü sırasında driver tarafından alınmış bir donanım register snapshot'ıydı.
Binary'den Kaynak Koda Doğru
APCheckBcnQHandler()'ın MIPS assembly'sini takip ettiğimizde içeride bir problem/recovery sayacı bulunduğunu gördük.
Tam kaynak kod elimizde olmadığı için değişken isimlerini bilmiyoruz; dolayısıyla aşağıdaki gerçek ASUS/MediaTek source'u değil, assembly'nin davranışını açıklamak için yazılmış pseudo-code:
if (beacon_problem_condition) {
problem_counter++;
...
if (problem_counter == 7) {
SetTxRxCr_Proc(pAd, "0");
}
...
if (problem_counter > 10) {
DumpBcnQMessage(...);
problem_counter = 0;
}
}
Buradaki en önemli bilinmeyen hâlâ:
beacon_problem_condition
Yani driver tam olarak ne gördüğünde bu sayacı artırıyor?
Beacon queue zamanında boşalmıyor mu?
PSE tarafında paket mi sıkışıyor?
DMA descriptor ilerlemiyor mu?
TX tarafındaki bir hardware counter mı değişmiyor?
Bunu henüz kesin olarak çözmedik.
Fakat 16:12 mesajının kaynağı artık oldukça iyi tanımlanmış durumda:
Wi-Fi subsystem
|
v
APCheckBcnQHandler()
|
v
problem/recovery counter
|
v
SetTxRxCr_Proc("0")
|
+-- 0x60330030
|
+-- 0x6033001C
Ve cihazımızın bıraktığı değerler:
0x60330030 = 0x92e8ff
0x6033001C = 0xffff
Driver'ın İçinde Daha Büyük Bir Diagnostic Mekanizması Var
SetTxRxCr_Proc() fonksiyonunu incelerken başka bir şey daha ortaya çıktı.
Fonksiyon yalnızca bu iki register'ı okuyabilmiyor.
Binary içerisinde:
RX Status Counter
0x6020410C
0x60204110
0x60204114
0x6020411C
0x60204120
ve:
CCA Status
0x60000024
0x60120118
0x60130110
0x60130114
0x60130118
0x60130120
0x60130124
0x60130128
gibi daha geniş diagnostic dump stringleri de bulunuyor.
Yani driver'ın kendi içinde TX/RX, RX status ve CCA tarafını incelemek için hazırlanmış bir debug mekanizması mevcut.
Bizim olayda kısa "0" modu çağrıldığı için yalnızca iki register görüyoruz.
Bu da ileride ilginç bir araştırma alanı açıyor:
Driver'ın mevcut diagnostic fonksiyonlarını firmware'i değiştirmeden tetikleyebilir miyiz?
Fakat şimdilik çalışan deney düzeneğine dokunmuyoruz.
Çünkü kara kutunun asıl amacı hâlâ aynı.
Gerçek kilitlenmeyi doğal haliyle yakalamak.
Sabahki Memory Failure ile Öğleden Sonraki Wi-Fi Olayı Bağlantılı mı?
Şu anda bilmiyoruz.
Ve bence bu deneyin en önemli taraflarından biri de burada.
Elimizde iki gerçek gözlem var:
04:36:45
|
+-- page allocation failure
+-- kmalloc-8192
+-- free = 200 kB
+-- SUnreclaim = 5740 kB
yaklaşık 11.5 saat
16:12:34
|
+-- APCheckBcnQHandler
+-- SetTxRxCr_Proc("0")
+-- 0x60330030 = 0x92e8ff
+-- 0x6033001C = 0xffff
Bunlardan hareketle birkaç hipotez kurulabilir.
Birinci ihtimal: Tamamen bağımsız iki olay.
16 MB RAM'li eski cihaz zaman zaman memory pressure yaşıyor, MediaTek Wi-Fi driver'ı da bağımsız olarak beacon queue recovery mekanizmasını çalıştırıyor olabilir.
İkinci ihtimal: Bellek baskısı Wi-Fi driver'ın zamanlamasını veya queue yönetimini etkiliyor olabilir.
Üçüncü ihtimal ise daha ilginç: Wi-Fi driver'daki TX/RX/PSE/buffer davranışı kernel slab kullanımını artırıyor olabilir.
Örneğin network nesneleri veya driver buffer'ları zamanında serbest kalmıyorsa önce slab büyür, ardından allocator baskı altına girebilir.
Ama bunların hiçbiri şu anda sonuç değil.
Yalnızca test edilebilir hipotezler.
Bir sonraki olayda aynı anda:
SUnreclaim
kmalloc-8192
kmalloc-4096
kmalloc-2048
buddyinfo
Wi-Fi register dump
değerlerini yakalayabilirsek tablo çok daha netleşecek.
Küçük Bir Cihaz, Oldukça Büyük Bir Yazılım Yığını
RP-N12'ye dışarıdan bakınca yaptığı iş çok basit görünüyor.
Ethernet'ten paket al.
Wi-Fi'dan gönder.
Fakat cihazın içinde:
Linux kernel
|
+-- SLUB allocator
+-- buddy allocator
+-- network stack
+-- bridge
+-- Ethernet driver
|
+-- MediaTek Wi-Fi driver
|
+-- DMA
+-- TX/RX rings
+-- PSE
+-- beacon queues
+-- watchdog/recovery
çalışıyor.
Ve bunların tamamının paylaşabileceği fiziksel RAM:
16 MiB.
Belki RP-N12'nin yaşadığı problem tek bir “bug” bile değildir.
Eski kernel, küçük RAM, eski vendor driver'ı, yoğun network trafiği ve zaman zaman oluşan fragmentation birlikte cihazı sınırda çalıştırıyor olabilir.
Bunu henüz bilmiyoruz.
Ama ilk bölümde kurduğumuz kara kutu sayesinde artık tahmin etmek zorunda değiliz.
Cihaz bize kendi içinden veri veriyor.
Kara Kutu Çalışmaya Devam Ediyor
İlk ciddi kayıtta Linux'un bellek ayıramadığını gördük.
İkinci ilginç kayıtta Wi-Fi driver'ın beacon/TX tarafındaki recovery mekanizmasına ulaştık.
Sonra ASUS'un yıllar önce yayınladığı kaynak paketini açıp 1.6 MB'lık MIPS kernel modülünü disassemble ederek syslog'daki iki anlamsız hexadecimal satırın hangi fonksiyondan çıktığını bulduk.
Ama aradığımız esas olay henüz gerçekleşmedi.
RP-N12 henüz tamamen kilitlenmedi.
Dolayısıyla deney devam ediyor.
Bir gün ping cevap vermeyi bıraktığında asıl bakacağımız şey cihazın öldüğü an olmayacak.
Ondan önceki birkaç saniye ve dakika olacak.
Kernel belleği ne durumdaydı?
Slab büyüyor muydu?
Beacon queue tekrar takılmış mıydı?
MediaTek recovery mekanizması çalışmış mıydı?
Ethernet hâlâ paket geçiriyor muydu?
Watchdog bir şey fark etmiş miydi?
Kara kutuyu kurmamızın nedeni tam olarak buydu.
Part 1'de RP-N12'yi dinlemeye başladık.
Part 2'de cihaz ilk kez gerçekten konuştu.
Bir sonraki bölümde ise tornavidayı alıyoruz.
ASUS RP-N12 · Embedded Linux · Linux 2.6.36 · MediaTek/Ralink · MT7628 · SLUB · kmalloc · Memory Pressure · Wi-Fi · Beacon Queue · MIPS · Reverse Engineering · Remote Syslog
