Date: Wed, 6 Aug 2014 18:17:58 +0200 From: Oliver Pinter <oliver.pntr@gmail.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: freebsd-hackers@freebsd.org, Matt Fleming <matt@console-pimps.org> Subject: Re: Sanity Check: Bogus(?) General Protection Fault Message-ID: <CAPjTQNFnN8BGevzpGmaxQepP0%2B-%2BZWPk1fU1jyrkcurwG%2Bc%2BSA@mail.gmail.com> In-Reply-To: <53E24FF0.7030305@vangyzen.net> References: <53E237B6.4040703@vangyzen.net> <20140806144833.GE15082@console-pimps.org> <53E24FF0.7030305@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Try to remove CPUTYPE?=foo from make.conf. On 8/6/14, Eric van Gyzen <eric@vangyzen.net> wrote: > 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) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNFnN8BGevzpGmaxQepP0%2B-%2BZWPk1fU1jyrkcurwG%2Bc%2BSA>