From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261282AbVHAVSv (ORCPT ); Mon, 1 Aug 2005 17:18:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261258AbVHAVRD (ORCPT ); Mon, 1 Aug 2005 17:17:03 -0400 Received: from graphe.net ([209.204.138.32]:3529 "EHLO graphe.net") by vger.kernel.org with ESMTP id S261289AbVHAVQt (ORCPT ); Mon, 1 Aug 2005 17:16:49 -0400 Date: Mon, 1 Aug 2005 14:16:44 -0700 (PDT) From: Christoph Lameter X-X-Sender: christoph@graphe.net To: Richard Purdie cc: Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: 2.6.13-rc3-mm3 In-Reply-To: <1122930474.7648.119.camel@localhost.localdomain> Message-ID: References: <20050728025840.0596b9cb.akpm@osdl.org> <1122860603.7626.32.camel@localhost.localdomain> <1122926537.7648.105.camel@localhost.localdomain> <1122930474.7648.119.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -5.8 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Aug 2005, Richard Purdie wrote: > On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote: > > Could you get me some more information about the hang? A stacktrace would > > be useful. > > I've attached gdb to it and its stuck in memcpy (from glibc). The rest > of the trace is junk as glibc's arm memcpy implementation will have > destroyed the frame pointer. The current instruction is a store to > memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't > changing... IP Not changing? Could it be in a loop doing faults for the same memory location that you cannot observe with gdb? Or is there some hardware fault that has stopped the processor?