1NOTE: this description applies to the hp300 system with the old BSD 2virtual memory system. It has not been updated to reflect the new, 3Mach-derived VM system, but should still be useful. 4The new system has no fixed-address "u.", but has a fixed mapping 5for the kernel stack at 0xfff00000. 6 7-------------------------------------------------------------------------- 8 9Some quick notes on the HPBSD VM layout and kernel debugging. 10 11Physical memory: 12 13Physical memory always ends at the top of the 32 bit address space; i.e. the 14last addressible byte is at 0xFFFFFFFF. Hence, the start of physical memory 15varies depending on how much memory is installed. The kernel variable "lowram" 16contains the starting locatation of memory as provided by the ROM. 17 18The low 128k (I think) of the physical address space is occupied by the ROM. 19This is accessible via /dev/mem *only* if the kernel is compiled with DEBUG. 20[ Maybe it should always be accessible? ] 21 22Virtual address spaces: 23 24The hardware page size is 4096 bytes. The hardware uses a two-level lookup. 25At the highest level is a one page segment table which maps a page table which 26maps the address space. Each 4 byte segment table entry (described in 27hp300/pte.h) contains the page number of a single page of 4 byte page table 28entries. Each PTE maps a single page of address space. Hence, each STE maps 294Mb of address space and one page containing 1024 STEs is adequate to map the 30entire 4Gb address space. 31 32Both page and segment table entries look similar. Both have the page frame 33in the upper part and control bits in the lower. This is the opposite of 34the VAX. It is easy to convert the page frame number in an STE/PTE to a 35physical address, simply mentally mask out the low 12 bits. For example 36if a PTE contains 0xFF880019, the physical memory location mapped starts at 370xFF880000. 38 39Kernel address space: 40 41The kernel resides in its own virtual address space independent of all user 42processes. When the processor is in supervisor mode (i.e. interrupt or 43exception handling) it uses the kernel virtual mapping. The kernel segment 44table is called Sysseg and is allocated statically in hp300/locore.s. The 45kernel page table is called Systab is also allocated statically in 46hp300/locore.s and consists of the usual assortment of SYSMAPs. 47The size of Systab (Syssize) depends on the configured size of the various 48maps but as currently configured is 9216 PTEs. Both segment and page tables 49are initialized at bootup in hp300/locore.s. The segment table never changes 50(except for bits maintained by the hardware). Portions of the page table 51change as needed. The kernel is mapped into the address space starting at 0. 52 53Theoretically, any address in the range 0 to Syssize * 4096 (0x2400000 as 54currently configured) is valid. However, certain addresses are more common 55in dumps than others. Those are (for the current configuration): 56 57 0 - 0x800000 kernel text and permanent data structures 58 0x917000 - 0x91a000 u-area; 1st page is user struct, last k-stack 59 0x1b1b000 - 0x2400000 user page tables, also kmem_alloc()ed data 60 61User address space: 62 63The user text and data are loaded starting at VA 0. The user's stack starts 64at 0xFFF00000 and grows toward lower addresses. The pages above the user 65stack are used by the kernel. From 0xFFF00000 to 0xFFF03000 is the u-area. 66The 3 PTEs for this range map (read-only) the same memory as does 0x917000 67to 0x91a000 in the kernel address space. This address range is never used 68by the kernel, but exists for utilities that assume that the u-area sits 69above the user stack. The pages from FFF03000 up are not used. They 70exist so that the user stack is in the same location as in HPUX. 71 72The user segment table is allocated along with the page tables from Usrptmap. 73They are contiguous in kernel VA space with the page tables coming before 74the segment table. Hence, a process has p_szpt+1 pages allocated starting 75at kernel VA p_p0br. 76 77The user segment table is typically very sparse since each entry maps 4Mb. 78There are usually only two valid STEs, one at the start mapping the text/data 79potion of the page table, and one at the end mapping the stack/u-area. For 80example if the segment table was at 0xFFFFA000 there would be valid entries 81at 0xFFFFA000 and 0xFFFFAFFC. 82 83Random notes: 84 85An important thing to note is that there are no hardware length registers 86on the HP. This implies that we cannot "pack" data and stack PTEs into the 87same page table page. Hence, every user page table has at least 2 pages 88(3 if you count the segment table). 89 90The HP maintains the p0br/p0lr and p1br/p1lr PCB fields the same as the 91VAX even though they have no meaning to the hardware. This also keeps many 92utilities happy. 93 94There is no seperate interrupt stack (right now) on the HPs. Interrupt 95processing is handled on the kernel stack of the "current" process. 96 97Following is a list of things you might want to be able to do with a kernel 98core dump. One thing you should always have is a ps listing from the core 99file. Just do: 100 101 ps klaw vmunix.? vmcore.? 102 103Exception related panics (i.e. those detected in hp300/trap.c) will dump 104out various useful information before panicing. If available, you should 105get this out of the /usr/adm/messages file. Finally, you should be in adb: 106 107 adb -k vmunix.? vmcore.? 108 109Adb -k will allow you to examine the kernel address space more easily. 110It automatically maps kernel VAs in the range 0 to 0x2400000 to physical 111addresses. Since the kernel and user address spaces overlap (i.e. both 112start at 0), adb can't let you examine the address space of the "current" 113process as it does on the VAX. 114-------- 115 1161. Find out what the current process was at the time of the crash: 117 118If you have the dump info from /usr/adm/messages, it should contain the 119PID of the active process. If you don't have this info you can just look 120at location "Umap". This is the PTE for the first page of the u-area; i.e. 121the user structure. Forget about the last 3 hex digits and compare the top 1225 to the ADDR column in the ps listing. 123 1242. Locating a process' user structure: 125 126Get the ADDR field of the desired process from the ps listing. This is the 127page frame number of the process' user structure. Tack 3 zeros on to the 128end to get the physical address. Note that this doesn't give you the kernel 129stack since it is in a different page than the user-structure and pages of 130the u-area are not physically contiguous. 131 1323. Locating a process' proc structure: 133 134First find the process' user structure as described above. Find the u_procp 135field at offset 0x200 from the beginning. This gives you the kernel VA of 136the proc structure. 137 1384. Locating a process' page table: 139 140First find the process' user structure as described above. The first part 141of the user structure is the PCB. The second longword (third field) of the 142PCB is pcb_ustp, a pointer to the user segment table. This pointer is 143actually the page frame number. Again adding 3 zeros yields the physical 144address. You can now use the values in the segment table to locate the 145page tables. For example, to locate the first page of the text/data part 146of the page table, use the first STE (longword) in the segment table. 147 1485. Locating a process' kernel stack: 149 150First find the process' page table as described above. The kernel stack 151is near the end of the user address space. So, locate the last entry in the 152user segment table (base+0xFFC) and use that entry to find the last page of 153the user page table. Look at the last 256 entries of this page 154(pagebase+0xFE0) The first is the PTE for the user-structure. The second 155was intended to be a read-only page to protect the user structure from the 156kernel stack. Currently it is read/write and actually allocated. Hence 157it can wind up being a second page for the kernel stack. The third is the 158kernel stack. The last 253 should be zero. Hence, indirecing through the 159third of these last 256 PTEs will give you the kernel stack page. 160 161An alternate way to do this is to use the p_addr field of the proc structure 162which is found as described above. The p_addr field is at offset 0x10 in the 163proc structure and points to the first of the PTEs mentioned above (i.e. the 164user structure PTE). 165 1666. Interpreting the info in a "trap type N..." panic: 167 168As mentioned, when the kernel crashes out of hp300/trap.c it will dump some 169useful information. This dates back to the days when I was debugging the 170exception handling code and had no kernel adb or even kernel crash dump code. 171"trap type" (decimal) is as defined in hp300/trap.h, it doesn't really 172correlate with anything useful. "code" (hex) is only useful for MMU 173(trap type 8) errors. It is the concatination of the MMU status register 174(see hp300/cpu.h) in the high 16 bits and the 68020 special status word 175(see the 020 manual page 6-17) in the low 16. "v" (hex) is the virtual 176address which caused the fault. "pid" (decimal) is the ID of the process 177running at the time of the exception. Note that if we panic in an interrupt 178routine, this process may not be related to the panic. "ps" (hex) is the 179value of the 68020 status register (see page 1-4 of 020 manual) at the time 180of the crash. If the 0x2000 bit is on, we were in supervisor (kernel) mode 181at the time, otherwise we were in user mode. "pc" (hex) is the value of the 182PC saved on the hardware exception frame. It may *not* be the PC of the 183instruction causing the fault (see the 020 manual for details). The 0x2000 184bit of "ps" dictates whether this is a kernel or user VA. "sfc" and "dfc" 185are the 68020 source/destination function codes. They should always be one. 186"p0" and "p1" are the VAX-like region registers. They are of the form: 187 188 <length> '@' <kernel VA> 189 190where both are in hex. Following these values are a dump of the processor 191registers (hex). Check the address registers for values close to "v", the 192fault address. Most faults are causes by dereferences of bogus pointers. 193Most such dereferences are the result of 020 instructions using the: 194 195 <address-register> '@' '(' offset ')' 196 197addressing mode. This can help you track down the faulting instruction (since 198the PC may not point to it). Note that the value of a7 (the stack pointer) is 199ALWAYS the user SP. This is brain-dead I know. Finally, is a dump of the 200stack (user/kernel) at the time of the offense. Before kernel crash dumps, 201this was very useful. 202 2037. Converting kernel virtual address to a physical address. 204 205Adb -k already does this for you, but sometimes you want to know what the 206resulting physical address is rather than what is there. Doing this is 207simply a matter of indexing into the kernel page table. In theory we would 208first have to do a lookup in the kernel segment table, but we know that the 209kernel page table is physically contiguous so this isn't necessary. The 210base of the system page table is "Sysmap", so to convert an address V just 211divide the address by 4096 to get the page number, multiply that by 4 (the 212size of a PTE in bytes) to get a byte offset, and add that to "Sysmap". 213This gives you the address of the PTE mapping V. You can then get the 214physical address by masking out the low 12 bits of the contents of that PTE. 215To wit: 216 217 *(Sysmap+(VA%1000*4))&fffff000 218 219where VA is the virtual address in question. 220 221This technique should also work for user virtual addresses if you replace 222"Sysmap" with the value of the appropriate processes' P0BR. This works 223because a user's page table is *virtually* contiguous in the kernel 224starting at P0BR, and adb will handle translating the kernel virtual addresses 225for you. 226