| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | okay, here are some hints for debugging the lower-level parts of |
| 2 | linux/parisc. |
| 3 | |
| 4 | |
| 5 | 1. Absolute addresses |
| 6 | |
| 7 | A lot of the assembly code currently runs in real mode, which means |
| 8 | absolute addresses are used instead of virtual addresses as in the |
| 9 | rest of the kernel. To translate an absolute address to a virtual |
| 10 | address you can lookup in System.map, add __PAGE_OFFSET (0x10000000 |
| 11 | currently). |
| 12 | |
| 13 | |
| 14 | 2. HPMCs |
| 15 | |
| 16 | When real-mode code tries to access non-existent memory, you'll get |
| 17 | an HPMC instead of a kernel oops. To debug an HPMC, try to find |
| 18 | the System Responder/Requestor addresses. The System Requestor |
| 19 | address should match (one of the) processor HPAs (high addresses in |
| 20 | the I/O range); the System Responder address is the address real-mode |
| 21 | code tried to access. |
| 22 | |
| 23 | Typical values for the System Responder address are addresses larger |
| 24 | than __PAGE_OFFSET (0x10000000) which mean a virtual address didn't |
| 25 | get translated to a physical address before real-mode code tried to |
| 26 | access it. |
| 27 | |
| 28 | |
| 29 | 3. Q bit fun |
| 30 | |
| 31 | Certain, very critical code has to clear the Q bit in the PSW. What |
| 32 | happens when the Q bit is cleared is the CPU does not update the |
| 33 | registers interruption handlers read to find out where the machine |
| 34 | was interrupted - so if you get an interruption between the instruction |
| 35 | that clears the Q bit and the RFI that sets it again you don't know |
| 36 | where exactly it happened. If you're lucky the IAOQ will point to the |
| 37 | instrucion that cleared the Q bit, if you're not it points anywhere |
| 38 | at all. Usually Q bit problems will show themselves in unexplainable |
| 39 | system hangs or running off the end of physical memory. |