I have a dragonboard410c which is based on arm64 and when it boots , it shows the memory layout:
software IO TLB [mem 0xb6c00000-0xbac00000] (64MB) mapped at [ff]
Memory: 780212K/951296K available (9940K kernel code, 1294K rwda)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000 ( 246 )
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 )
0xffffffbdc0000000 - 0xffffffbdc1000000 ( 16 )
fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 ( 4108 )
PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 ( 16 )
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 )
memory : 0xffffffc000000000 - 0xffffffc040000000 ( 1024 )
.init : 0xffffffc000e49000 - 0xffffffc000f43000 ( 1000 )
.text : 0xffffffc000080000 - 0xffffffc000e483e4 ( 14113 )
I could not find an explanation of the meaning of it.
especialy what is the vmemmap region ? and why are there two address interval for it?
Also, what are the "fixed" and the "memory" zones ?
I found out that whenever I use kmalloc no meter with what flag, I get an address that is from the memory region. Even if I use vmalloc , the address I receive is not from the vmalloc region.
So is it possible to use regions other than the memory region in a kernel module ?
Related
We have a NDIS LWF driver, and on a single machine we get a DPC_WATCHDOG_VIOLATION 133/1 bugcheck when they try to connect to their VPN to connect to the internet. This could be related to our NdisFIndicateReceiveNetBufferLists, as the IRQL is raised to DISPATCH before calling it (and obviously lowered to whatever it was afterward), and that does appear in the output of !dpcwatchdog shown below. This is done due to a workaround for another bug explained here:
IRQL_UNEXPECTED_VALUE BSOD after NdisFIndicateReceiveNetBufferLists?
Now this is the bugcheck:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above. The offending component can usually be
identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: fffff805422fb320, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
additional information regarding the cumulative timeout
Arg4: 0000000000000000
STACK_TEXT:
nt!KeBugCheckEx
nt!KeAccumulateTicks+0x1846b2
nt!KiUpdateRunTime+0x5d
nt!KiUpdateTime+0x4a1
nt!KeClockInterruptNotify+0x2e3
nt!HalpTimerClockInterrupt+0xe2
nt!KiCallInterruptServiceRoutine+0xa5
nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
nt!KiInterruptDispatchNoLockNoEtw+0x37
nt!KxWaitForSpinLockAndAcquire+0x2c
nt!KeAcquireSpinLockAtDpcLevel+0x5c
wanarp!WanNdisReceivePackets+0x4bb
ndis!ndisMIndicateNetBufferListsToOpen+0x141
ndis!ndisMTopReceiveNetBufferLists+0x3f0e4
ndis!ndisCallReceiveHandler+0x61
ndis!ndisInvokeNextReceiveHandler+0x1df
ndis!NdisMIndicateReceiveNetBufferLists+0x104
ndiswan!IndicateRecvPacket+0x596
ndiswan!ApplyQoSAndIndicateRecvPacket+0x20b
ndiswan!ProcessPPPFrame+0x16f
ndiswan!ReceivePPP+0xb3
ndiswan!ProtoCoReceiveNetBufferListChain+0x442
ndis!ndisMCoIndicateReceiveNetBufferListsToNetBufferLists+0xf6
ndis!NdisMCoIndicateReceiveNetBufferLists+0x11
raspptp!CallIndicateReceived+0x210
raspptp!CallProcessRxNBLs+0x199
ndis!ndisDispatchIoWorkItem+0x12
nt!IopProcessWorkItem+0x135
nt!ExpWorkerThread+0x105
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x28
SYMBOL_NAME: wanarp!WanNdisReceivePackets+4bb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: wanarp
IMAGE_NAME: wanarp.sys
And this following is the output of !dpcwatchdog, but I still can't find what is causing this bugcheck, and can't find which function is consuming too much time in DISPATCH level which is causing this bugcheck. Although I think this could be related to some spin locking done by wanarp? Could this be a bug with wanarp? Note that we don't use any spinlocking in our driver, and us raising the IRQL should not cause any issue as it is actually very common for indication in Ndis to be done at IRQL DISPATCH.
So How can I find the root cause of this bugcheck? There are no other third party LWF in the ndis stack.
3: kd> !dpcwatchdog
All durations are in seconds (1 System tick = 15.625000 milliseconds)
Circular Kernel Context Logger history: !logdump 0x2
DPC and ISR stats: !intstats /d
--------------------------------------------------
CPU#0
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
dpcs: no pending DPCs found
--------------------------------------------------
CPU#1
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
1: Normal : 0xfffff80542220e00 0xfffff805418dbf10 nt!PpmCheckPeriodicStart
1: Normal : 0xfffff80542231d40 0xfffff8054192c730 nt!KiBalanceSetManagerDeferredRoutine
1: Normal : 0xffffbd0146590868 0xfffff80541953200 nt!KiEntropyDpcRoutine
DPC Watchdog Captures Analysis for CPU #1.
DPC Watchdog capture size: 641 stacks.
Number of unique stacks: 1.
No common functions detected!
The captured stacks seem to indicate that only a single DPC or generic function is the culprit.
Try to analyse what other processors were doing at the time of the following reference capture:
CPU #1 DPC Watchdog Reference Stack (#0 of 641) - Time: 16 Min 17 Sec 984.38 mSec
# RetAddr Call Site
00 fffff805418d8991 nt!KiUpdateRunTime+0x5D
01 fffff805418d2803 nt!KiUpdateTime+0x4A1
02 fffff805418db1c2 nt!KeClockInterruptNotify+0x2E3
03 fffff80541808a45 nt!HalpTimerClockInterrupt+0xE2
04 fffff805419fab9a nt!KiCallInterruptServiceRoutine+0xA5
05 fffff805419fb107 nt!KiInterruptSubDispatchNoLockNoEtw+0xFA
06 fffff805418a9a9c nt!KiInterruptDispatchNoLockNoEtw+0x37
07 fffff805418da3cc nt!KxWaitForSpinLockAndAcquire+0x2C
08 fffff8054fa614cb nt!KeAcquireSpinLockAtDpcLevel+0x5C
09 fffff80546ba1eb1 wanarp!WanNdisReceivePackets+0x4BB
0a fffff80546be0b84 ndis!ndisMIndicateNetBufferListsToOpen+0x141
0b fffff80546ba7ef1 ndis!ndisMTopReceiveNetBufferLists+0x3F0E4
0c fffff80546bddfef ndis!ndisCallReceiveHandler+0x61
0d fffff80546ba4a94 ndis!ndisInvokeNextReceiveHandler+0x1DF
0e fffff8057c32d17e ndis!NdisMIndicateReceiveNetBufferLists+0x104
0f fffff8057c30d6c7 ndiswan!IndicateRecvPacket+0x596
10 fffff8057c32d56b ndiswan!ApplyQoSAndIndicateRecvPacket+0x20B
11 fffff8057c32d823 ndiswan!ProcessPPPFrame+0x16F
12 fffff8057c308e62 ndiswan!ReceivePPP+0xB3
13 fffff80546c5c006 ndiswan!ProtoCoReceiveNetBufferListChain+0x442
14 fffff80546c5c2d1 ndis!ndisMCoIndicateReceiveNetBufferListsToNetBufferLists+0xF6
15 fffff8057c2b0064 ndis!NdisMCoIndicateReceiveNetBufferLists+0x11
16 fffff8057c2b06a9 raspptp!CallIndicateReceived+0x210
17 fffff80546bd9dc2 raspptp!CallProcessRxNBLs+0x199
18 fffff80541899645 ndis!ndisDispatchIoWorkItem+0x12
19 fffff80541852b65 nt!IopProcessWorkItem+0x135
1a fffff80541871d25 nt!ExpWorkerThread+0x105
1b fffff80541a00778 nt!PspSystemThreadStartup+0x55
1c ---------------- nt!KiStartSystemThread+0x28
--------------------------------------------------
CPU#2
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
2: Normal : 0xffffbd01467f0868 0xfffff80541953200 nt!KiEntropyDpcRoutine
DPC Watchdog Captures Analysis for CPU #2.
DPC Watchdog capture size: 641 stacks.
Number of unique stacks: 1.
No common functions detected!
The captured stacks seem to indicate that only a single DPC or generic function is the culprit.
Try to analyse what other processors were doing at the time of the following reference capture:
CPU #2 DPC Watchdog Reference Stack (#0 of 641) - Time: 16 Min 17 Sec 984.38 mSec
# RetAddr Call Site
00 fffff805418d245a nt!KeClockInterruptNotify+0x453
01 fffff80541808a45 nt!HalpTimerClockIpiRoutine+0x1A
02 fffff805419fab9a nt!KiCallInterruptServiceRoutine+0xA5
03 fffff805419fb107 nt!KiInterruptSubDispatchNoLockNoEtw+0xFA
04 fffff805418a9a9c nt!KiInterruptDispatchNoLockNoEtw+0x37
05 fffff805418a9a68 nt!KxWaitForSpinLockAndAcquire+0x2C
06 fffff8054fa611cb nt!KeAcquireSpinLockRaiseToDpc+0x88
07 fffff80546ba1eb1 wanarp!WanNdisReceivePackets+0x1BB
08 fffff80546be0b84 ndis!ndisMIndicateNetBufferListsToOpen+0x141
09 fffff80546ba7ef1 ndis!ndisMTopReceiveNetBufferLists+0x3F0E4
0a fffff80546bddfef ndis!ndisCallReceiveHandler+0x61
0b fffff80546be3a81 ndis!ndisInvokeNextReceiveHandler+0x1DF
0c fffff80546ba804e ndis!ndisFilterIndicateReceiveNetBufferLists+0x3C611
0d fffff8054e384d77 ndis!NdisFIndicateReceiveNetBufferLists+0x6E
0e fffff8054e3811a9 ourdriver+0x4D70
0f fffff80546ba7d40 ourdriver+0x11A0
10 fffff8054182a6b5 ndis!ndisDummyIrpHandler+0x100
11 fffff80541c164c8 nt!IofCallDriver+0x55
12 fffff80541c162c7 nt!IopSynchronousServiceTail+0x1A8
13 fffff80541c15646 nt!IopXxxControlFile+0xC67
14 fffff80541a0aab5 nt!NtDeviceIoControlFile+0x56
15 ---------------- nt!KiSystemServiceCopyEnd+0x25
--------------------------------------------------
CPU#3
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
dpcs: no pending DPCs found
Target machine version: Windows 10 Kernel Version 19041 MP (4 procs)
Also note that we also pass the NDIS_RECEIVE_FLAGS_DISPATCH_LEVEL flag to the NdisFIndicateReceiveNetBufferLists, if the current IRQL is dispatch.
Edit1:
This is also the output of !locks and !qlocks and !ready, And the contention count on one of the resources is 49135, is this normal or too high? Could this be related to our issue? The threads that are waiting on it or own it are for normal processes such as chrome, csrss, etc.
3: kd> !kdexts.locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks.
Resource # nt!ExpTimeRefreshLock (0xfffff80542219440) Exclusively owned
Contention Count = 17
Threads: ffffcf8ce9dee640-01<*>
KD: Scanning for held locks.....
Resource # 0xffffcf8cde7f59f8 Shared 1 owning threads
Contention Count = 62
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks...............................................................................................
Resource # 0xffffcf8ce08d0890 Exclusively owned
Contention Count = 49135
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 6
Threads: ffffcf8cf18e3080-01<*> ffffcf8ce3faf080-01
Threads Waiting On Exclusive Access:
ffffcf8ceb6ce080 ffffcf8ce1d20080 ffffcf8ce77f1080 ffffcf8ce92f4080
ffffcf8ce1d1f0c0 ffffcf8ced7c6080
KD: Scanning for held locks.
Resource # 0xffffcf8ce08d0990 Shared 1 owning threads
Threads: ffffcf8cf18e3080-01<*>
KD: Scanning for held locks.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Resource # 0xffffcf8ceff46350 Shared 1 owning threads
Threads: ffffcf8ce6de8080-01<*>
KD: Scanning for held locks......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Resource # 0xffffcf8cf0cade50 Exclusively owned
Contention Count = 3
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks.........................
Resource # 0xffffcf8cf0f76180 Shared 1 owning threads
Threads: ffffcf8ce83dc080-02<*>
KD: Scanning for held locks.......................................................................................................................................................................................................................................................
Resource # 0xffffcf8cf1875cb0 Shared 1 owning threads
Contention Count = 3
Threads: ffffcf8ce89db040-02<*>
KD: Scanning for held locks.
Resource # 0xffffcf8cf18742d0 Shared 1 owning threads
Threads: ffffcf8cee5e1080-02<*>
KD: Scanning for held locks....................................................................................
Resource # 0xffffcf8cdceeece0 Shared 2 owning threads
Contention Count = 4
Threads: ffffcf8ce3a1c080-01<*> ffffcf8ce5625040-01<*>
Resource # 0xffffcf8cdceeed48 Shared 1 owning threads
Threads: ffffcf8ce5625043-02<*> *** Actual Thread ffffcf8ce5625040
KD: Scanning for held locks...
Resource # 0xffffcf8cf1d377d0 Exclusively owned
Threads: ffffcf8cf0ff3080-02<*>
KD: Scanning for held locks....
Resource # 0xffffcf8cf1807050 Exclusively owned
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks......
245594 total locks, 13 locks currently held
3: kd> !qlocks
Key: O = Owner, 1-n = Wait order, blank = not owned/waiting, C = Corrupt
Processor Number
Lock Name 0 1 2 3
KE - Unused Spare
MM - Unused Spare
MM - Unused Spare
MM - Unused Spare
CC - Vacb
CC - Master
EX - NonPagedPool
IO - Cancel
CC - Unused Spare
IO - Vpb
IO - Database
IO - Completion
NTFS - Struct
AFD - WorkQueue
CC - Bcb
MM - NonPagedPool
3: kd> !ready
KSHARED_READY_QUEUE fffff8053f1ada00: (00) ****------------------------------------------------------------
SharedReadyQueue fffff8053f1ada00: No threads in READY state
Processor 0: No threads in READY state
Processor 1: Ready Threads at priority 15
THREAD ffffcf8ce9dee640 Cid 2054.2100 Teb: 000000fab7bca000 Win32Thread: 0000000000000000 READY on processor 1
Processor 2: No threads in READY state
Processor 3: No threads in READY state
3: kd> dt nt!_ERESOURCE 0xffffcf8ce08d0890
+0x000 SystemResourcesList : _LIST_ENTRY [ 0xffffcf8c`e08d0610 - 0xffffcf8c`e08cf710 ]
+0x010 OwnerTable : 0xffffcf8c`ee6e8210 _OWNER_ENTRY
+0x018 ActiveCount : 0n1
+0x01a Flag : 0xf86
+0x01a ReservedLowFlags : 0x86 ''
+0x01b WaiterPriority : 0xf ''
+0x020 SharedWaiters : 0xffffae09`adcae8e0 Void
+0x028 ExclusiveWaiters : 0xffffae09`a9aabea0 Void
+0x030 OwnerEntry : _OWNER_ENTRY
+0x040 ActiveEntries : 1
+0x044 ContentionCount : 0xbfef
+0x048 NumberOfSharedWaiters : 1
+0x04c NumberOfExclusiveWaiters : 6
+0x050 Reserved2 : (null)
+0x058 Address : (null)
+0x058 CreatorBackTraceIndex : 0
+0x060 SpinLock : 0
3: kd> dx -id 0,0,ffffcf8cdcc92040 -r1 (*((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8ce08d08c0))
(*((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8ce08d08c0)) [Type: _OWNER_ENTRY]
[+0x000] OwnerThread : 0xffffcf8cf18e3080 [Type: unsigned __int64]
[+0x008 ( 0: 0)] IoPriorityBoosted : 0x0 [Type: unsigned long]
[+0x008 ( 1: 1)] OwnerReferenced : 0x0 [Type: unsigned long]
[+0x008 ( 2: 2)] IoQoSPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 (31: 3)] OwnerCount : 0x1 [Type: unsigned long]
[+0x008] TableSize : 0xc [Type: unsigned long]
3: kd> dx -id 0,0,ffffcf8cdcc92040 -r1 ((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8cee6e8210)
((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8cee6e8210) : 0xffffcf8cee6e8210 [Type: _OWNER_ENTRY *]
[+0x000] OwnerThread : 0x0 [Type: unsigned __int64]
[+0x008 ( 0: 0)] IoPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 ( 1: 1)] OwnerReferenced : 0x1 [Type: unsigned long]
[+0x008 ( 2: 2)] IoQoSPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 (31: 3)] OwnerCount : 0x0 [Type: unsigned long]
[+0x008] TableSize : 0x7 [Type: unsigned long]
Thanks for reporting this. I've tracked this down to an OS bug: there's a deadlock in wanarp. This issue appears to affect every version of the OS going back to Windows Vista.
I've filed internal issue task.ms/42393356 to track this: if you have a Microsoft support contract, your rep can get you status updates on that issue.
Meanwhile, you can partially work around this issue by either:
Indicating 1 packet at a time (NumberOfNetBufferLists==1); or
Indicating on a single CPU at a time
The bug in wanarp is exposed when 2 or more CPUs collectively process 3 or more NBLs at the same time. So either workaround would avoid the trigger conditions.
Depending on how much bandwidth you're pushing through this network interface, those options could be rather bad for CPU/battery/throughput. So please try to avoid pessimizing batching unless it's really necessary. (For example, you could make this an option that's off-by-default, unless the customer specifically uses wanarp.)
Note that you cannot fully prevent the issue yourself. Other drivers in the stack, including NDIS itself, have the right to group packets together, which would have the side effect re-batching the packets that you carefully un-batched. However, I believe that you can make a statistically significant dent in the crashes if you just indicate 1 NBL at a time, or indicate multiple NBLs on 1 CPU at a time.
Sorry this is happening to you again! wanarp is... a very old codebase.
I am trying with ESP32-S2 WROOM (full name: LilyGO TTGO T8 ESP32-S2 WROOM) to read the input from an i2s microphone(sph0645), and all I get is either silence or a noise (if the assigned pin is not in the microphone fits) so the connection must be correct, I think. I get 1 error message namely E (10715) AUDIO_ELEMENT: [wav] Element already stopped. This error message is nowhere to be found on the espressif forum so I have become a bit hopeless: P also good to know that this is my first post on this topic. So if you know a little more about how to make these two components (i2s microphone and esp32-s2) work, feel free!
To complete the story, this is the complete log.
(64) boot: ESP-IDF v4.2-dirty 2nd stage bootloader
I (64) boot: compile time 15:26:45
I (64) boot: chip revision: 0
I (66) boot.esp32s2: SPI Speed : 80MHz
I (71) boot.esp32s2: SPI Mode : DIO
I (76) boot.esp32s2: SPI Flash Size : 4MB
I (81) boot: Enabling RNG early entropy source...
I (86) boot: Partition Table:
I (90) boot: ## Label Usage Type ST Offset Length
I (97) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (104) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (112) boot: 2 factory factory app 00 00 00010000 00100000
I (119) boot: End of partition table
I (124) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f000020 size=0x0dafc ( 56060) map
I (144) esp_image: segment 1: paddr=0x0001db24 vaddr=0x3ffbf260 size=0x01f70 ( 8048) load
I (147) esp_image: segment 2: paddr=0x0001fa9c vaddr=0x40024000 size=0x00404 ( 1028) load
0x40024000: _WindowOverflow4 at C:/Users/kraan/esp/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1730I (153) esp_image: segment 3: paddr=0x0001fea8 vaddr=0x40024404 size=0x00170 ( 368) load
I (162) esp_image: segment 4: paddr=0x00020020 vaddr=0x40080020 size=0x2a02c (172076) map
0x40080020: _stext at ??:?I (206) esp_image: segment 5: paddr=0x0004a054 vaddr=0x40024574 size=0x0ace4 ( 44260) load
I (225) boot: Loaded app from partition at offset 0x10000
I (225) boot: Disabling RNG early entropy source...
I (225) cache: Instruction cache : size 8KB, 4Ways, cache line size 32Byte
I (233) cpu_start: Pro cpu up.
I (236) cpu_start: Application information:
I (241) cpu_start: Project name: record_wav
I (246) cpu_start: App version: 1
I (251) cpu_start: Compile time: Mar 4 2021 15:26:18
I (257) cpu_start: ELF file SHA256: f689f9b5ef13ab60...
I (263) cpu_start: ESP-IDF: v4.2-dirty
I (268) cpu_start: Single core mode
D (272) memory_layout: Checking 3 reserved memory ranges:
D (278) memory_layout: Reserved memory range 0x3ffb4000 - 0x3ffbf258
D (284) memory_layout: Reserved memory range 0x3ffbf260 - 0x3ffc1a20
D (291) memory_layout: Reserved memory range 0x3ffffa10 - 0x40000000
D (297) memory_layout: Building list of available memory regions:
D (303) memory_layout: Available memory region 0x3ffc1a20 - 0x3ffc4000
D (310) memory_layout: Available memory region 0x3ffc4000 - 0x3ffc8000
D (316) memory_layout: Available memory region 0x3ffc8000 - 0x3ffcc000
D (323) memory_layout: Available memory region 0x3ffcc000 - 0x3ffd0000
D (330) memory_layout: Available memory region 0x3ffd0000 - 0x3ffd4000
D (336) memory_layout: Available memory region 0x3ffd4000 - 0x3ffd8000
D (343) memory_layout: Available memory region 0x3ffd8000 - 0x3ffdc000
D (349) memory_layout: Available memory region 0x3ffdc000 - 0x3ffe0000
D (356) memory_layout: Available memory region 0x3ffe0000 - 0x3ffe4000
D (363) memory_layout: Available memory region 0x3ffe4000 - 0x3ffe8000
D (369) memory_layout: Available memory region 0x3ffe8000 - 0x3ffec000
D (376) memory_layout: Available memory region 0x3ffec000 - 0x3fff0000
D (382) memory_layout: Available memory region 0x3fff0000 - 0x3fff4000
D (389) memory_layout: Available memory region 0x3fff4000 - 0x3fff8000
D (396) memory_layout: Available memory region 0x3fff8000 - 0x3fffc000
D (402) memory_layout: Available memory region 0x3fffc000 - 0x3ffffa10
I (409) heap_init: Initializing. RAM available for dynamic allocation:
D (416) heap_init: New heap initialised at 0x3ffc1a20
I (421) heap_init: At 3FFC1A20 len 0003A5E0 (233 KiB): DRAM
I (427) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM
I (433) cpu_start: Pro cpu start user code
D (491) clk: RTC_SLOW_CLK calibration value: 5765894
D (497) intr_alloc: Connected src 49 to int 2 (cpu 0)
D (497) intr_alloc: Connected src 73 to int 10 (cpu 0)
D (497) intr_alloc: Connected src 28 to int 3 (cpu 0)
D (503) FLASH_HAL: extra_dummy: 0
D (506) spi_flash: trying chip: issi
D (510) spi_flash: trying chip: gd
D (513) spi_flash: trying chip: mxic
D (517) spi_flash: trying chip: generic
I (521) spi_flash: detected chip: generic
I (526) spi_flash: flash io: dio
I (530) cpu_start: Starting scheduler on PRO CPU.
D (535) heap_init: New heap initialised at 0x3fffc000
D (535) intr_alloc: Connected src 17 to int 9 (cpu 0)
I (545) REC_WAV_SDCARD: [ 1 ] Mount sdcard
D (545) intr_alloc: Connected src 23 to int 12 (cpu 0)
D (555) intr_alloc: Connected src 34 to int 13 (cpu 0)
I (605) REC_WAV_SDCARD: [ 2 ] Start codec chip
I (605) REC_WAV_SDCARD: [3.0] Create audio pipeline for recording
I (605) REC_WAV_SDCARD: [3.1] Create fatfs stream to write data to sdcard
I (615) REC_WAV_SDCARD: [3.2] Create i2s stream to read audio data from codec chip
D (625) intr_alloc: Connected src 35 to int 19 (cpu 0)
I (635) REC_WAV_SDCARD: [3.3] Create wav encoder to encode wav format
I (635) REC_WAV_SDCARD: [3.4] Register all elements to audio pipeline
I (645) REC_WAV_SDCARD: [3.5] Link it together [codec_chip]-->i2s_stream-->wav_encoder-->fatfs_stream-->[sdcard]
I (655) REC_WAV_SDCARD: [3.6] Set up uri (file as fatfs_stream, wav as wav encoder)
I (665) REC_WAV_SDCARD: [ 4 ] Set up event listener
I (665) REC_WAV_SDCARD: [4.1] Listening event from pipeline
I (675) REC_WAV_SDCARD: [4.2] Listening event from peripherals
I (685) REC_WAV_SDCARD: [ 5 ] Start audio_pipeline
I (695) REC_WAV_SDCARD: [ 6 ] Listen for all pipeline events, record for 10 Seconds
I (1715) REC_WAV_SDCARD: [ * ] Recording ... 1
I (2715) REC_WAV_SDCARD: [ * ] Recording ... 2
I (3715) REC_WAV_SDCARD: [ * ] Recording ... 3
I (4715) REC_WAV_SDCARD: [ * ] Recording ... 4
I (5715) REC_WAV_SDCARD: [ * ] Recording ... 5
I (6715) REC_WAV_SDCARD: [ * ] Recording ... 6
I (7715) REC_WAV_SDCARD: [ * ] Recording ... 7
I (8715) REC_WAV_SDCARD: [ * ] Recording ... 8
I (9715) REC_WAV_SDCARD: [ * ] Recording ... 9
I (10715) REC_WAV_SDCARD: [ * ] Recording ... 10
I (10715) REC_WAV_SDCARD: [ 7 ] Stop audio_pipeline
W (10715) AUDIO_ELEMENT: IN-[wav] AEL_IO_ABORT
E (10715) AUDIO_ELEMENT: [wav] Element already stopped
W (10725) AUDIO_ELEMENT: IN-[file] AEL_IO_ABORT
W (10735) AUDIO_PIPELINE: There are no listener registered
W (10735) AUDIO_ELEMENT: [file] Element has not create when AUDIO_ELEMENT_TERMINATE
W (10745) AUDIO_ELEMENT: [i2s] Element has not create when AUDIO_ELEMENT_TERMINATE
W (10755) AUDIO_ELEMENT: [wav] Element has not create when AUDIO_ELEMENT_TERMINATE
Looking for some help with making an output from a MegaCli command a bit more readable.
The output is:
PS C:\Users\Administrator> C:\Users\Administrator\Downloads\8-04-07_MegaCLI\Win_CliKL_8.04.07\MegaCliKL -LDInfo -Lall -aAll
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :OS
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 558.375 GB
Mirror Data : 558.375 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives : 2
Span Depth : 1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
Bad Blocks Exist: No
Is VD Cached: Yes
Cache Cade Type : Read Only
Virtual Drive: 1 (Target Id: 1)
Name :Storage
RAID Level : Primary-0, Secondary-0, RAID Level Qualifier-0
Size : 7.275 TB
Parity Size : 0
State : Optimal
Strip Size : 64 KB
Number Of Drives : 4
Span Depth : 1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
Bad Blocks Exist: No
Is VD Cached: Yes
Cache Cade Type : Read Only
Exit Code: 0x00
The command I'm using is:
C:\Users\Administrator\Downloads\8-04-07_MegaCLI\Win_CliKL_8.04.07\MegaCliKL -LDInfo -Lall -aAll
How can I make that information a bit more readable?
I only actually need: Name, Raid Level, Size, Number of drives, State, and Span Depth.
It has to be doable in just powershell.
Thanks in advance for any help!
Zack
If "a bit more readable" means "reduce output merely to lines starting with listed items":
$MegaCliKL = & C:\Users\Administrator\Downloads\8-04-07_MegaCLI\Win_CliKL_8.04.07\MegaCliKL -LDInfo -Lall -aAll
$listedItems = '^\s*Name',
'Raid Level',
'Size',
'Number of drives',
'State',
'Span Depth' -join '|^\s*'
$MegaCliKL -match $listedItems |
ForEach-Object {
if ( $_ -match '^\s*Name' ) {''} # line separator
$_
}
Output:
Name :OS
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 558.375 GB
State : Optimal
Number Of Drives : 2
Span Depth : 1
Name :Storage
RAID Level : Primary-0, Secondary-0, RAID Level Qualifier-0
Size : 7.275 TB
State : Optimal
Number Of Drives : 4
Span Depth : 1
In embedded platform built by petalinux, during boot(from u-boot), the last print I see is(sometimes) mmcblk0boot1 print.
What are the good ways to debug/trace/fix the problem?
As you can see at the end of the log is the start of another boot
The attached log
=======================================================================
> U-Boot 2015.07 (Jul 22 2018 - 14:04:29 +0300)
> DRAM: ECC disabled 511 MiB
> MMC: Max clock 26000000, Min clock 0
> zynq_sdhci: 0
> SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
> In: serial
> Out: serial
> Err: serial
> Net: Gem.e000b000
> U-BOOT for AAS_TOP_V0_00_12
> Hit any key to stop autoboot: 4 3 2 1 0
> Device: zynq_sdhci
> Manufacturer ID: fe
> OEM: 14e
> Name: MMC04
> Tran Speed: 26000000
> Rd Block Len: 512
> MMC version 4.4.1
> High Capacity: Yes
> Capacity: 3.5 GiB
> Bus Width: 4-bit
> Erase Group Size: 512 KiB
> HC WP Group Size: 4 MiB
> User Capacity: 3.5 GiB
> Boot Capacity: 16 MiB ENH
> RPMB Capacity: 128 KiB ENH
> reading image.ub
> 7775932 bytes read in 750 ms (9.9 MiB/s)
> ## Loading kernel from FIT Image at 01000000 ...
> Using 'conf#1' configuration
> Verifying Hash Integrity ... OK
> Trying 'kernel#1' kernel subimage
> Description: PetaLinux Kernel
> Type: Kernel Image
> Compression: gzip compressed
> Data Start: 0x010000f0
> Data Size: 7760664 Bytes = 7.4 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x00008000
> Entry Point: 0x00008000
> Hash algo: crc32
> Hash value: 53e3bbd8
> Verifying Hash Integrity ... crc32+ OK
> ## Loading fdt from FIT Image at 01000000 ...
> Using 'conf#1' configuration
> Trying 'fdt#1' fdt subimage
> Description: Flattened Device Tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x01766cec
> Data Size: 13972 Bytes = 13.6 KiB
> Architecture: ARM
> Hash algo: crc32
> Hash value: bdcc1805
> Verifying Hash Integrity ... crc32+ OK
> Booting using the fdt blob at 0x1766cec
> Uncompressing Kernel Image ... OK
> Loading Device Tree to 07ff9000, end 07fff693 ... OK
Starting kernel:
> Starting kernel ...
> Booting Linux on physical CPU 0x0
> Linux version 4.0.0-xilinx (alex#ubuntu) (gcc version 4.9.2
> (SourceryCodeBench Lite 2015.05-17) ) #3 SMP PREEMPT Sun Nov 12 10:10:19
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: MY_MACHINE
> bootconsole [earlycon0] enabled
> cma: Reserved 16 MiB at 0x1ec00000
> Memory policy: Data cache writealloc
> PERCPU: Embedded 11 pages/cpu #dfecf000 s12672 r8192 d24192 u45056
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129794
> Kernel command line: console=ttyPS0,115200 earlyprintk
> PID hash table entries: 2048 (order: 1, 8192 bytes)
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 490876K/523264K available (4763K kernel code, 223K rwdata, 1708K
> rodata, 4376K init, 208K bss, 16004K reserved, 16384K cma-reserved, 0K
>highmem)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xe0000000 - 0xff000000 ( 496 MB)
> lowmem : 0xc0000000 - 0xdff00000 ( 511 MB)
> pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> .text : 0xc0008000 - 0xc0659f7c (6472 kB)
> .init : 0xc065a000 - 0xc0aa0000 (4376 kB)
> .data : 0xc0aa0000 - 0xc0ad7e60 ( 224 kB)
> .bss : 0xc0ad7e60 - 0xc0b0c174 ( 209 kB)
> Preemptible hierarchical RCU implementation.
> Additional per-CPU info printed with stalls.
> RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> NR_IRQS:16 nr_irqs:16 16
> L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
> L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
> L2C-310 erratum 769419 enabled
> L2C-310 enabling early BRESP for Cortex-A9
> L2C-310 full line of zeros enabled for Cortex-A9
> L2C-310 ID prefetch enabled, offset 1 lines
> L2C-310 dynamic clock gating enabled, standby mode enabled
> L2C-310 cache controller enabled, 8 ways, 512 kB
> L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
> slcr mapped to e0004000
> zynq_clock_init: clkc starts at e0004100
> Zynq clock init
> sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 3298534883328ns
> timer #0 at e0008000, irq=17
> Console: colour dummy device 80x30
> Calibrating delay loop... 1332.01 BogoMIPS (lpj=6660096)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> CPU: Testing write buffer coherency: ok
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x482348 - 0x4823a0
> CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> Brought up 2 CPUs
> SMP: Total of 2 processors activated (2664.03 BogoMIPS).
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
> pinctrl core: initialized pinctrl subsystem
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> cpuidle: using governor ladder
> cpuidle: using governor menu
> hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
> hw-breakpoint: maximum watchpoint size is 4 bytes.
> zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB # 0xe0080000
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> media: Linux media interface: v0.10
> Linux video capture interface: v2.00
> pps_core: LinuxPPS API ver. 1 registered
> pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
> <giometti#linux.it>
> PTP clock support registered
> EDAC MC: Ver: 3.0.0
> Advanced Linux Sound Architecture Driver Initialized.
> Switched to clocksource arm_global_timer
> NET: Registered protocol family 2
> TCP established hash table entries: 4096 (order: 2, 16384 bytes)
> TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP: reno registered
> UDP hash table entries: 256 (order: 1, 8192 bytes)
> UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters
> available
> futex hash table entries: 512 (order: 3, 32768 bytes)
> jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
> dma-pl330 f8003000.dmac: Loaded driver for PL330 DMAC-241330
> dma-pl330 f8003000.dmac: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4
> Num_Events-16
> e0000000.serial: ttyPS1 at MMIO 0xe0000000 (irq = 144, base_baud = 3125000)
> is a xuartps
> e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 145, base_baud = 3125000)
> is a xuartps
> �console [ttyPS0] enabled
> console [ttyPS0] enabled
> bootconsole [earlycon0] disabled
> bootconsole [earlycon0] disabled
> xdevcfg f8007000.devcfg: ioremap 0xf8007000 to e006c000
> [drm] Initialized drm 1.1.0 20060810
> brd: module loaded
> loop: module loaded
> CAN device driver interface
> libphy: MACB_mii_bus: probed
> macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq
> 149 (00:0a:35:00:1e:53)
> macb e000b000.ethernet eth0: attached PHY driver [Marvell 88E1510]
> (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
> e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
> e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-pci: EHCI PCI platform driver
> usbcore: registered new interface driver usb-storage
> mousedev: PS/2 mouse device common for all mice
> i2c /dev entries driver
> at24 0-0050: 1024 byte 24c08 EEPROM, writable, 1 bytes/write
> cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 141
> Xilinx Zynq CpuIdle Driver started
> Driver 'mmcblk' needs updating - please use bus_type methods
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> sdhci-arasan e0101000.sdhci: No vmmc regulator found
> sdhci-arasan e0101000.sdhci: No vqmmc regulator found
> mmc0: SDHCI controller on e0101000.sdhci [e0101000.sdhci] using ADMA
> ledtrig-cpu: registered to indicate activity on CPUs
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> NET: Registered protocol family 17
> can: controller area network core (rev 20120528 abi 9)
> NET: Registered protocol family 29
> can: raw protocol (rev 20120528)
> can: broadcast manager protocol (rev 20120528 t)
> can: netlink gateway (rev 20130117) max_hops=1
> Registering SWP/SWPB emulation handler
> /home/alex/Petalinux/petalinux-v2015.4-final/components/linux-kernel/xlnx-
> 4.0/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> ALSA device list:
> No soundcards found.
> Freeing unused kernel memory: 4376K (c065a000 - c0aa0000)
> mmc0: MAN_BKOPS_EN bit is not set
> mmc0: new high speed MMC card at address 0001
>
> INIT: mmcblk0: mmc0:0001 MMC04G 3.52 GiB
> mmcblk0boot0: mmc0:0001 MMC04G partition 1 16.0 MiB
> mmcblk0boot1: mmc0:0001 MMC04G partition 2 16.0 MiB
> U-Boot 2015.07 (Jul 22 2018 - 14:04:29 +0300)
Can't understand how Windows Memory Manager works.
I look at the attached user process (dbgview.exe).
It is WOW64-process. At the specified address (0x76560000) there is .text section of the kernel32.dll module (also WOW64).
Why there is no PTE and other tables in the process page table pointing to those virtual address?
kd> db 76560000
00000000`76560000 8b ff 55 8b ec 51 56 57-33 f6 89 55 fc 56 68 80 ..U..QVW3..U.Vh.
<...>
kd> !pte 76560000
VA 0000000076560000
PXE at FFFFF6FB7DBED000 PPE at FFFFF6FB7DA00008 PDE at FFFFF6FB40001D90 PTE at FFFFF680003B2B00
Unable to get PXE FFFFF6FB7DBED000
kd> db FFFFF680003B2B00
fffff680`003b2b00 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????
<...>
I know that pages will be allocated after first access (with page fault) have occured, but why there is no protype PTE too?
Firstly, translate an arbitrary virtual address to physical using !vtop to see the dirbase of the process in the process of translation, or use !process to find the dirbase of the process:
lkd> .process /p fffffa8046a2e5f0
Implicit process is now fffffa80`46a2e5f0
lkd> .context 77fa90000
lkd> !vtop 0 13fe60000
Amd64VtoP: Virt 00000001`3fe60000, pagedir 7`7fa90000
Amd64VtoP: PML4E 7`7fa90000
Amd64VtoP: PDPE 1`c2e83020
Amd64VtoP: PDE 7`84e04ff8
Amd64VtoP: PTE 4`be585300
Amd64VtoP: Mapped phys 6`3efae000
Virtual address 13fe60000 translates to physical address 63efae000.
Then find that physical frame in the PFN database (in this case the physical page for PML4 (cr3 page aka. dirbase) is 77fa90 with full physical address 77fa90000:
lkd> !pfn 77fa90
PFN 0077FA90 at address FFFFFA80167EFB00
flink FFFFFA8046A2E5F0 blink / share count 00000005 pteaddress FFFFF6FB7DBEDF68
reference count 0001 used entry count 0000 Cached color 0 Priority 0
restore pte 00000080 containing page 77FA90 Active M
Modified
The address FFFFF6FB7DBED000 is therefore the virtual address of the PML4 page and FFFFF6FB7DBEDF68 is the virtual address of the PML4E self reference entry (1ed*8 = f68).
FFFFF6FB7DBED000 = 1111111111111111111101101111101101111101101111101101000000000000
1111111111111111 111101101 111101101 111101101 111101101 000000000000
The PML4 can only be at a virtual address where the PML4E, PDTPE, PDE and PTE index are the same, so there are actually 2^9 different combinations of that and windows 7 always selects 0x1ed i.e. 111101101. The reason for this is because the PML4 contains a PML4 that points to itself i.e. the physical frame of the PML4, so it will need to keep indexing to that same location at every level of the hierarchy.
The PML4, being a page table page, must reside in the kernel, and kernel addresses are high-canonical, i.e. prefixed with 1111111111111111, and kernel addresses begin with 00001 through 11111 i.e. from 08 to ff
The range of possible addresses that a 64 bit OS that uses 8TiB for user address space can place it at is therefore 31*(2^4) = 496 different possible locations and not actually 2^9:
1111111111111111 000010000 000010000 000010000 000010000 000000000000
1111111111111111 111111111 111111111 111111111 111111111 000000000000
I.e. the first is FFFF080402010000, the second is FFFF088442211000, the last is FFFFFFFFFFFFF000.
Note:
Up until Windows 10 TH2, the magic index for the Self-Reference PML4 entry was 0x1ed as mentioned above. But what about Windows 10 from 1607? Well Microsoft uped their game, as a constant battle for improving Windows security the index is randomized at boot-time, so 0x1ed is now one of the 512 [sic. (496)] possible values (i.e. 9-bit index) that the Self-Reference entry index can have. And side effect, it also broke some of their own tools, like the !pte2va WinDbg command.
0xFFFFF68000000000 is the address of the first PTE in the first page table page, so basically MmPteBase, except because on Windows 10 1607 the PML4E can be an other than 0x1ed, the base is not always 0xFFFFF68000000000 as a result, and it uses a variable nt!MmPteBase to know instantly where the base of the page table page allocations begins. Previously, this symbol does not exist in ntoskrnl.exe, because it has a hardcoded base 0xFFFFF68000000000. The address of the first and last page table page is going to be:
first last
* pml4e_offset : 0x1ed 0x1ed
* pdpe_offset : 0x000 0x1ff
* pde_offset : 0x000 0x1ff
* pte_offset : 0x000 0x1ff
* offset : 0x000 0x000
This gives 0xFFFFF68000000000 for the first and 0xFFFFF6FFFFFFF000 for the last page table page when the PML4E index is 0x1ed. PDEs + PDPTEs + PML4Es + PTEs are assigned in this range.
Therefore, to be able to translate a virtual address to its PTE virtual address (and !pte2va is the reverse of this), you affix 111101101 to the start of the virtual address and then you truncate the last 12 bits (the page offset, which is no longer useful) and then you times it by 8 bytes (the PTE size) (i.e. add 3 zeroes to the end, which creates a new page offset from the last level index into the page that contains the PTEs times the size of a PTE structure). Concatenating the PML4E index to the start simply causes it to loop back one time such that you actually get the PTE rather than what the PTE points to. Concatenating it to the start is the same thing as adding it to MmPteBase.
Here is simple C++ code to do it:
// pte.cpp
#include<iostream>
#include<string>
int main(int argc, char *argv[]) {
unsigned long long int input = std::stoull(argv[1], nullptr, 16);
long long int ptebase = 0xFFFFF68000000000;
long long int pteaddress = ptebase + ((input >> 12) << 3);
std::cout << "0x" << std::hex << pteaddress;
}
C:\> pte 13fe60000
0xfffff680009ff300
To get the PDE virtual address you have to affix it twice and then truncate the last 21 bits and then times by 8. This is how !pte is supposed to work, and is the opposite of !pte2va.
Similarly, PDEs + PDPTEs + PML4Es are assigned in the range:
first last
* pml4e_offset : 0x1ed 0x1ed
* pdpe_offset : 0x1ed 0x1ed
* pde_offset : 0x000 0x1ff
* pte_offset : 0x000 0x1ff
* offset : 0x000 0x000
Because when you get to 0x1ed for the pdpte offset within the page table page range, all of a sudden, you are looping back in the PML4 once again, so you get the PDE.
If it says there is no PTE for an address within a virtual page for which the corresponding physical frame is shown to be part of the working set by VMMap, then you might be experiencing my issue, where you need to use .process /P if you're doing live kernel debugging (local or remote) to explicitly tell the debugger that you want to translate user and kernel addresses in the context of the process and not the debugger.
I have found that since Windows 10 Anniversary Update (1607, 10.0.14393) PML4 table had been randomized to mitigate kernel heap spraying.
It means that probably Page Table is not placed at 0xFFFFF6800000.