What is the purpose of the magic SysRq dump register function?

Question

无论我运行Sysrq处理程序多少次，代码中特定位置的寄存器似乎都不会改变。

Answer 1

What is the purpose of the magic SysRq dump register function?

The purpose is, just as you probably expect, to show the current state of the system. That it never changed on yours must be due to the implementation or how you run the Sysrq handler (perhaps echo p >/proc/sysrq-trigger ).
On a system here, when I do the SysRq P from the console, I get different output, eg:

SysRq : Show Regs
NIP: c0010c9c LR: 00000000 CTR: 00000000
REGS: c049d2c0 TRAP: 0000   Not tainted  (2.6.34)
MSR: 00009032 <EE,ME,IR,DR>  CR: 00000000  XER: 00000000
TASK = cf852760[194] 'gatekeeper/0' THREAD: cfaba000
GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
NIP [c0010c8c] __delay+0x40/0x84
LR [00000000] (null)
Call Trace:
[cfabbcd0] [c0009a74] show_stack+0xac/0x1d8 (unreliable)
[cfabbd20] [c000a1bc] show_regs+0x1c8/0x310
[cfabbd50] [c026d190] sysrq_handle_showregs+0x34/0x50
[cfabbd60] [c026d61c] __handle_sysrq+0xcc/0x1a8
[cfabbd90] [c026d7bc] handle_sysrq+0x44/0x5c
[cfabbdb0] [c02735e4] mpc52xx_psc_handle_irq+0x538/0x604
[cfabbe10] [c0272d78] mpc52xx_uart_int+0x38/0x50
[cfabbe20] [c0070b04] handle_IRQ_event+0x90/0x1f8
[cfabbe50] [c0073ca4] handle_level_irq+0x74/0xf0
[cfabbe70] [c0006864] handle_one_irq+0x40/0x58
[cfabbe90] [c000d180] __ipipe_do_IRQ+0x48/0x68
[cfabbeb0] [c0076c08] __ipipe_sync_stage+0x1f0/0x24c
[cfabbee0] [c007722c] __ipipe_unstall_root+0x50/0x74
[cfabbef0] [c002ad80] finish_task_switch+0x40/0xb8
[cfabbf10] [c03935c8] schedule+0x240/0x4c8
[cfabbf60] [c00afe34] gatekeeper_thread+0x190/0x1e0
[cfabbfc0] [c0054bf0] kthread+0x88/0x8c
[cfabbff0] [c0015648] kernel_thread+0x4c/0x68
Instruction dump:
81698020 800b000c 70090040 41820040 7d2c42e6 7c0c42e6 7c090050 7f801840
409c0018 7c210b78 <7c0c42e6> 7c090050 7f830040 419dfff0 7c421378 81610000

or

SysRq : Show Regs
NIP: c0010c88 LR: 00000000 CTR: 00000000
REGS: c049d2c0 TRAP: 0000   Not tainted  (2.6.34)
MSR: 00009032 <EE,ME,IR,DR>  CR: 00000000  XER: 00000000
TASK = c049c4b0[0] 'swapper' THREAD: c04c0000
GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
NIP [c0010cf0] udelay+0x20/0x3c
LR [00000000] (null)
Call Trace:
[c04c1c50] [c0009a74] show_stack+0xac/0x1d8 (unreliable)
[c04c1ca0] [c000a1bc] show_regs+0x1c8/0x310
[c04c1cd0] [c026d190] sysrq_handle_showregs+0x34/0x50
[c04c1ce0] [c026d61c] __handle_sysrq+0xcc/0x1a8
[c04c1d10] [c026d7bc] handle_sysrq+0x44/0x5c
[c04c1d30] [c02735e4] mpc52xx_psc_handle_irq+0x538/0x604
[c04c1d90] [c0272d78] mpc52xx_uart_int+0x38/0x50
[c04c1da0] [c0070b04] handle_IRQ_event+0x90/0x1f8
[c04c1dd0] [c0073ca4] handle_level_irq+0x74/0xf0
[c04c1df0] [c0006864] handle_one_irq+0x40/0x58
[c04c1e10] [c000d180] __ipipe_do_IRQ+0x48/0x68
[c04c1e30] [c0076c08] __ipipe_sync_stage+0x1f0/0x24c
[c04c1e60] [c0076e5c] __ipipe_walk_pipeline+0x104/0x128
[c04c1e80] [c000cc9c] __ipipe_handle_irq+0x154/0x16c
[c04c1eb0] [c000cdd4] __ipipe_grab_irq+0x4c/0x8c
[c04c1ec0] [c0016168] __ipipe_ret_from_except+0x0/0xc
--- Exception: 501 at cpu_idle+0xac/0xf0
    LR = cpu_idle+0xac/0xf0
[c04c1f80] [c000ad18] cpu_idle+0x6c/0xf0 (unreliable)
[c04c1fa0] [c0003e90] rest_init+0x70/0xa0
[c04c1fb0] [c045da04] start_kernel+0x2c8/0x2e0
[c04c1ff0] [00003438] 0x3438
Instruction dump:
3d20c04d 93e1000c 7c3f0b78 81698020 800b000c 70090040 41820040 7d2c42e6
7c0c42e6 7c090050 7f801840 409c0018 <7c210b78> 7c0c42e6 7c090050 7f830040