Aklınıza gelen; hayattaki her şeyde olduğu gibi, <bir mikroişlemci> de her zaman tutarlı bir şekilde ağır iş yüküyle karşılaşmaz. Aslında, senin, benim gibi bir kullanıcı için çoğu zaman mikroişlemci hiçbir şey yapmasa bile çok az işlem yapar. Atıl/Idle bir işlemci, herhangi bir yararlı iş yapmayan bir işlemcidir. Bir odadan çıkarken ışıkları kapattığınız zaman olduğu gibi, işlemci herhangi bir yararlı iş yapmadığı için anlık olarak kapatılabilir.
Tıpkı çökmenin yaşanmadığı bir çekirdekte gerçekleşen olaylar gibi; mevcut çökme 14. işlemci çekirdeğinde gerçekleşiyor, bu durumda 1.çekirdekteki işlemcinin boş bir durumda olduğuna dair rapor vermesi gayet olağan ve normal bir şeydir.
Kesinlikle bir çıkarım içermez.
Kod:
1: kd> k
# Child-SP RetAddr Call Site
00 ffffc388`4ce3e578 fffff807`66e53c4b amdppm!ReadIoMemRaw+0x5b
01 ffffc388`4ce3e580 fffff807`66e59b37 amdppm!ReadGenAddr+0x1f
02 ffffc388`4ce3e5b0 fffff807`66e518d3 amdppm!C2Idle+0x87
03 ffffc388`4ce3e5e0 fffff807`47ae15cf amdppm!AcpiCStateIdleExecute+0x23
04 ffffc388`4ce3e610 fffff807`47ae114b nt!PpmIdleExecuteTransition+0x41f
05 ffffc388`4ce3ea50 fffff807`47c1d034 nt!PoIdle+0x68b
06 ffffc388`4ce3ec40 00000000`00000000 nt!KiIdleLoop+0x54
C2 durumu, işlemcideki G/Ç işleminin kapandığını ve kesmelere yanıt vermediğini gösteren bir işaretten fazlası değildir. Kesme istek düzeyine bakınca da anlıyoruz ki bu işlemcide bir kayıt alınmıyor, normalen bu durumda da bu işlemci bir rapor sunmuyor ve bir durumu özetlemiyor.
Kod:
1: kd> r if
if=0 <<
1: kd> !irql
Debugger saved IRQL for processor 0x1 -- 0 (LOW_LEVEL) <<
Modern mikroişlemciler diyelim; Bunlar, işlemcinin kapatılan giderek daha büyük bir bölümünü temsil eden birkaç C durumuna sahip olabilirler. Buradaki mikroişlemciden kastımız çekirdekler olduğunu ve bunların daha sıkı altsınıflara ayrıldığını da söylemek gerek. Daha yüksek C durumları için daha fazla güç tasarrufu eylemi gerçekleştirilir. C1-2-3 durumları, tek bir çekirdeğin boşta kalma durumuyla ilgilidir. Örneğin C0/C durumu olması gereken durumdur, bu durumda işlemci boşta değildir ve aslında yapması gereken işleri yapmakla meşguldür. Bu ilk durum boşta kalma durumu olarak düşünülebilir. C1/ C durumu ilk işlemcinin boşta olduğu durumdur. Bu durumda, Clock Tıne geçitli olur ve o çekirdeğin çalışmasını etkin bir şekilde kapatır. Başka daha yüksek durumlar da mevcut olarak vardır.
Intel'in de meselasında Hyper-Threading'i destekleyen
x86 işlemcileri gibi bazı sistemlerde iş parçacığı düzeyinde C durumlarının da mevcut olduğu bir gerçek ancak, her bir iş parçacığı daha yüksek C durumları talep edebilirken, herhangi bir güç tasarrufu eylemi yalnızca çekirdek C durumu (CC durumu) çözüldükten sonra gerçekleştirilir. Çekirdek C durumu, en düşük iş parçacığı durumu tarafından belirlenir:
Eki Görüntüle 32970
1-2 örnek kaynak forumu ile durumu toparlayabiliriz, farklı konulara sapıtmayalım.
*
Ryzen c-states / idle power draw
1.çekirdek kontrolü bu durumda gerekli midir? Kesinlikle hayır. 14.çekirdekteki çağrılar daha önemlidir:
Kod:
14: kd> k
# Child-SP RetAddr Call Site
00 ffffc388`4d595448 fffff807`47c2dc29 nt!KeBugCheckEx
01 ffffc388`4d595450 fffff807`47c29134 nt!KiBugCheckDispatch+0x69
02 ffffc388`4d595590 00000000`00000001 nt!KiPageFault+0x474
*** WARNING: Unable to verify timestamp for rtwlane_13.sys
03 ffffc388`4d595728 00000000`00000000 afd!AfdTLBufferedSendCompleteBatch
04 ffffc3884d595a78 fffff8074a9d0429 NETIO!NetioPhChecksumIpDatagramWithInitialChecksum+0x69
Kopma noktasını gördün mü?
rtwlane_13.sys yani,
Realtek PCIEWireless LAN PCI-E NIC hata vermiş. Sürücüsü de bayağı, bayağı eski.
[CODE highlight="11"]14: kd> lmDvmrtwlane_13
Browse full module list
start end module name
fffff807`54a00000 fffff807`54da9000 rtwlane_13 (deferred)
(.....)
C:\ProgramData\dbg\sym\rtwlane_13.sys\56FCBCF53a9000\rtwlane_13.sys
Image path: \SystemRoot\System32\drivers\rtwlane_13.sys
Image name: rtwlane_13.sys
(.....)
Browse all global symbols functions data
Timestamp:Thu Mar 31 09:00:21 2016 (56FCBCF5)[/CODE]
Her neyse, güncellemek yeterli olmayabilir. Zira 14.çekirdekteki /bir diğer dosya/ çağrılara dikkat et:
Bir adres alanını kaldırmak için
nt!MiCleanVad çağrısını görüyorsun ki bu çağrıların görevi sanal bellekteki adresleri fiziksel bellekteki adreslere eşlemek kısmında görev almalarıdır. Ardından farklı bir noktada bu adres alanı için sayfa tablolarını silen
nt!MiDeletePagablePteRange çağrısını görüyorsun. Daha sonra adres alanını silmek için başka bir çağrı, ardından adres alanını silmek için son bir çağrı ve ardından mavi ekrana neden olan hata kontrolünü görüyorsun.
Kod:
14: kd> k
# Child-SP RetAddr Call Site
00 ffff8107`bc909018 fffff807`6ec95e79 nt!KeBugCheckEx
01 ffff8107`bc909020 fffff807`6ec8e95e nt!MiDeletePteRun+0x17b9
02 ffff8107`bc909230 fffff807`6ec89f2b nt!MiDeleteVaTail+0x6e
03 ffff8107`bc909260 fffff807`6ec33920 nt!MiDeletePagablePteRange+0x4ab
04 ffff8107`bc909570 fffff807`6f05dd3b nt!MiDeleteVad+0x360
05 ffff8107`bc909680 fffff807`6f05c19f nt!MiCleanVad+0x43
06 ffff8107`bc9096b0 fffff807`6f085ef8 nt!MmCleanProcessAddressSpace+0x137
07 ffff8107`bc909730 fffff807`6f08da4e nt!PspRundownSingleProcess+0x20c
08 ffff8107`bc9097c0 fffff807`6f107f48 nt!PspExitThread+0x5f6
09 ffff8107`bc9098c0 fffff807`6ecc872d nt!KiSchedulerApcTerminate+0x38
0a ffff8107`bc909900 fffff807`6ee02ee0 nt!KiDeliverApc+0x60d
0b ffff8107`bc9099c0 fffff807`6ee1161f nt!KiInitiateUserApc+0x70
0c ffff8107`bc909b00 00007ffc`8838d064 nt!KiSystemServiceExit+0x9f
0d 000000e0`131cf678 00000000`00000000 0x00007ffc`8838d064
Bu durumda yaptığın şey yanlış, AM4 işlemcilerin 4 RAM'i Dual channel ayarına aldıkları bilinen bir gerçek. Senin bu RAM'leri OC sınırının altına getirip sistemi kontrol etmen gerekiyor. Bu da 2666MHz altına tekabül ediyor.
Bu da yanlış bir düşünce, Anakart desteklediği sürece istenilen hızlara çıkılabilir. RAM çiplerin /B Dıe vs./ ve işlemcindeki bellek kontrolcüsü gibi türlü türlü etkenler daha önemlidir bu noktada.
