From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 6 15:55:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5FB59E1 for ; Wed, 6 Aug 2014 15:55:30 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 73ECC2F5E for ; Wed, 6 Aug 2014 15:55:30 +0000 (UTC) Received: from marvin.beer.town (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5EEA756444; Wed, 6 Aug 2014 10:55:29 -0500 (CDT) Message-ID: <53E24FF0.7030305@vangyzen.net> Date: Wed, 06 Aug 2014 11:55:28 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Sanity Check: Bogus(?) General Protection Fault References: <53E237B6.4040703@vangyzen.net> <20140806144833.GE15082@console-pimps.org> In-Reply-To: <20140806144833.GE15082@console-pimps.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Matt Fleming X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:55:30 -0000 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 : 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 : mov 0x30(%rax),%r9 0xffffffff805d6e13 : shr $0x15,%r9 0xffffffff805d6e17 : shl $0x6,%r9 0xffffffff805d6e1b : mov 0xffffffff809bf7a8,%r11 0xffffffff805d6e23 : 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)