only print out DR registers if they are not power-on defaults.

The DR registers are rarely useful when decoding oopses.
With screen real estate during oopses at a premium, we can save two lines by only printing out these registers when they are set to something other than they power-on state.

Signed-off-by Dave Jones <[email protected]>

diff -durpN '--exclude-from=/home/davej/.exclude' /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c linux-dj/arch/x86/kernel/process_64.c

arch/x86/kernel/process_64.c renamed from home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c +0 -0

@@ -105,11 +105,18 @@ void __show_regs(struct pt_regs *regs, i
 	get_debugreg(d0, 0);

arch/x86/kernel/process_64.c renamed from home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c +4 -0

+		return;
+
+	printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, d2);
 	printk(KERN_DEFAULT "DR3: %016lx DR6: %016lx DR7: %016lx\n", d3, d6, d7);
+
 }
 
 void release_thread(struct task_struct *dead_task)

arch/x86/kernel/process_32.c +0 -0

index 7305f7d..5905dc5 100644
@@ -110,11 +110,16 @@ void __show_regs(struct pt_regs *regs, int all)
 	get_debugreg(d1, 1);
 	get_debugreg(d2, 2);

arch/x86/kernel/process_32.c +4 -0

+		return;
+
+	printk(KERN_DEFAULT "DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
+			d0, d1, d2, d3);
 	printk(KERN_DEFAULT "DR6: %08lx DR7: %08lx\n",
 			d6, d7);

Quoted 4 lines · Dave Jones

The DR registers are rarely useful when decoding oopses.
With screen real estate during oopses at a premium, we can save two lines by only printing out these registers when they are set to something other than they power-on state.

Makes sense, except...

Quoted 8 lines

Signed-off-by Dave Jones <[email protected]>

diff -durpN '--exclude-from=/home/davej/.exclude' /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c linux-dj/arch/x86/kernel/process_64.c

arch/x86/kernel/process_64.c renamed from home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c +0 -0

@@ -105,11 +105,18 @@ void __show_regs(struct pt_regs *regs, i
 	get_debugreg(d0, 0);

arch/x86/kernel/process_64.c void __show_regs(struct pt_regs *regs, i · line 114

Quoted 10 lines

arch/x86/kernel/process_64.c renamed from home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c +4 -1

 	get_debugreg(d1, 1);
 	get_debugreg(d2, 2);
-	printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, d2);
 	get_debugreg(d3, 3);
 	get_debugreg(d6, 6);
 	get_debugreg(d7, 7);
+
+	/* Only print out debug registers if they are in their non-default state. */
+	if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
+	    (d6 & ~DR6_RESERVED) && (d7 == 0x400))

... I'm not sure about %dr6. So we're not dumping %dr6 when, a.o. any of the bits in the bit slices [3:0], [15:13] are set (bit 12 is Read-As-Zero). Now those mean stuff like Breakpoint-Condition Detected or Debug-Register-Access Detected and so on and I think this is meaningful information.

So actually, we wouldn't want to dump %dr6 when its contents are its default contents, i.e, 0xffff0ff0, i.e. the test should be:

	(d6 == DR6_RESERVED)

no?

My intent here was to ignore cases where the reserved bits haven't been set. I occasionally see DR6: 00000000fffe0ff0 for eg.

But maybe you're right, and that is a clue and is worth printing ? I can't personally recall ever diagnosing a bug using those register dumps in the last 15 years.

The DR registers are rarely useful when decoding oopses.
With screen real estate during oopses at a premium, we can save two lines by only printing out these registers when they are set to something other than they power-on state.

[v2: incorporate D6 change suggested by Borislav Petkov <[email protected]>]

Signed-off-by Dave Jones <[email protected]>

Quoted 2 lines · Dave Jones

My intent here was to ignore cases where the reserved bits haven't been set. I occasionally see DR6: 00000000fffe0ff0 for eg.

That's bit 16 which, according to the docs is read-as-1:

"All remaining bits in the DR6 register are reserved. Reserved bits 31:16 and 11:4 must all be set to 1, while reserved bit 12 must be cleared to 0. In 64-bit mode, the upper 32 bits of DR6 are reserved and must be written with zeros. Writing a 1 to any of the upper 32 bits results in a general-protection exception, #GP(0)."

This above if from AMD APM and Intel's SDM has a graphic showing the exact same thing:

[31:16] = set to 1; [12] = 0b, [11:4] = 1b

So if you see bit 16 cleared, then some BIOS or even hardware is doing funky things. I wouldn't wonder at all if BIOS dudes used reserved bits in registers as scratch space.

Quoted 3 lines

But maybe you're right, and that is a clue and is worth printing ? I can't personally recall ever diagnosing a bug using those register dumps in the last 15 years.

Right, I don't know whether it would always help but if you have an oops and see, say bit 0 in DR6 set, i.e. a debug exception was caused by address breakpoint condition in DR0, then that could be useful info, methinks.

There is serious confusion with regards to DR6 about the bits which are *fixed* (forced to 1) and the ones which are *reserved* (should always have a fixed value.)

There are some bits in DR6 which are used by hardware probes.

Quoted 4 lines · H. Peter Anvin

There is serious confusion with regards to DR6 about the bits which are *fixed* (forced to 1) and the ones which are *reserved* (should always have a fixed value.)

Quoted 1 line

There are some bits in DR6 which are used by hardware probes.

Haha, I knew it! HW guys don't care about the architectural documents.

Maybe DR6 should probably be dropped altogether from the check before exiting __show_regs early?

Quoted 11 lines · Borislav Petkov

Quoted 5 lines · H. Peter Anvin

There is serious confusion with regards to DR6 about the bits which are *fixed* (forced to 1) and the ones which are *reserved* (should always have a fixed value.)

There are some bits in DR6 which are used by hardware probes.

Haha, I knew it! HW guys don't care about the architectural documents.

Maybe DR6 should probably be dropped altogether from the check before exiting __show_regs early?

Uhm... I think you're missing the point of architectural documents.

The architectural documents describe the contract between hardware and software. It doesn't mean that hardware can't go beyond it... it is in fact the norm. The architectural documentation states what software may rely on and within what bounds it can assume safe behavior to be compatible both now and with any future extensions.

From your comment above it sounded like we can't really rely on some of