Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 | |
c94bed8e | 37 | instruction that cleared the Q bit, if you're not it points anywhere |
1da177e4 LT |
38 | at all. Usually Q bit problems will show themselves in unexplainable |
39 | system hangs or running off the end of physical memory. |