Sanity Check: Bogus(?) General Protection Fault
Eric van Gyzen
eric at vangyzen.net
Wed Aug 6 15:55:30 UTC 2014
On 08/06/2014 10:48, Matt Fleming wrote:
> On Wed, 06 Aug, at 10:12:06AM, Eric van Gyzen wrote:
>> Can someone give me a quick sanity check? I'm debugging a General
>> Protection Fault on an amd64 system. The faulting instruction appears
>> to be an immediate mov into %r11...right? I ask because I can't imagine
>> how that instruction could cause a GPF. Any ideas?
>>
>> Thanks,
>>
>> Eric
>>
>> ====
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 0; apic id = 00
>> instruction pointer = 0x20:0xffffffff805d6e23
> [...]
>
>> 0xffffffff805d6e23 <vm_reserv_alloc_contig+947>: mov %rcx,0x10(%r11,%r9,1)
> This is your faulting instruction.
Thanks, Matt. That has always been my understanding (and I just found
the docs to confirm). I doubted myself because the problem is now even
more bizarre. The mov before the faulting instruction apparently didn't
complete. %r11 is still an old value, not 0x....f7a8.
Any ideas, anyone?
Eric
====
0xffffffff805d6e0f <vm_reserv_alloc_contig+927>: mov 0x30(%rax),%r9
0xffffffff805d6e13 <vm_reserv_alloc_contig+931>: shr $0x15,%r9
0xffffffff805d6e17 <vm_reserv_alloc_contig+935>: shl $0x6,%r9
0xffffffff805d6e1b <vm_reserv_alloc_contig+939>: mov
0xffffffff809bf7a8,%r11
0xffffffff805d6e23 <vm_reserv_alloc_contig+947>: mov
%rcx,0x10(%r11,%r9,1)
db> show reg
cs 0x20
ds 0x3b
es 0x3b003b
fs 0x1b0013
gs 0x1b
ss 0x28
rax 0xfffff8043efd6980
rcx 0xfffff80423501000
rdx 0xfffff80423501000
rbx 0xffffffffffdce222
rsp 0xfffffe0463d45660
rbp 0xfffffe0463d456d0
rsi 0xffffffff80a0f898 kernel_object_store+0xb0
rdi 0xffffffff80a0f7e8 kernel_object_store
r8 0
r9 0x1fffff0087dc0
r10 0
r11 0xfffff80423501000
r12 0xfffff80430b86980
r13 0x707e00
r14 0
r15 0
rip 0xffffffff805d6e23 vm_reserv_alloc_contig+0x3b3
rflags 0x10206
vm_reserv_alloc_contig+0x3b3: movq %rcx,0x10(%r11,%r9,1)
More information about the freebsd-hackers
mailing list