From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758284AbYEKTow (ORCPT ); Sun, 11 May 2008 15:44:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751761AbYEKToo (ORCPT ); Sun, 11 May 2008 15:44:44 -0400 Received: from mga12.intel.com ([143.182.124.36]:38867 "EHLO azsmga102.ch.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750959AbYEKTon (ORCPT ); Sun, 11 May 2008 15:44:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,469,1204531200"; d="scan'208";a="245253784" Message-ID: <48274C9E.3020608@linux.intel.com> Date: Sun, 11 May 2008 12:44:30 -0700 From: Arjan van de Ven User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vegard Nossum CC: Ingo Molnar , Linux Kernel Mailing List Subject: Re: Error in save_stack_trace() on x86_64? References: <19f34abd0805110609lf3180dm3b1078e373983ad7@mail.gmail.com> In-Reply-To: <19f34abd0805110609lf3180dm3b1078e373983ad7@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vegard Nossum wrote: > Hi, > > I am having a problem with v2.6.26-rc1 on x86_64. It seems that > save_stack_trace() is not able to follow page fault boundaries, since > all my saved traces look like this: > > RIP: 0010:[] [] add_uevent_var+0xb4/0x160 > ... > [] kmemcheck_read+0x127/0x1e0 > [] kmemcheck_access+0x179/0x1d0 > [] kmemcheck_fault+0x5f/0x80 > [] do_page_fault+0x4de/0x8d0 > [] error_exit+0x0/0x51 > [] 0xffffffffffffffff > > I have this in my .config: > > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_STACKTRACE=y > ... > CONFIG_FRAME_POINTER=y > ... > CONFIG_DEBUG_INFO=y > > > On 32-bit, I am able to see the calls leading up to the page fault as > well. Did I miss something here? can you give an example? if a pagefault happens in userspace this trace looks correct. if it happens in kernel space... I wonder if the separate exception stack thing is hurting us with the stacks not being properly connected... (but oopses and the like seem to come out just fine so I kinda doubt you're hitting that)