From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21774 invoked by alias); 22 Nov 2005 11:00:58 -0000 Received: (qmail 21766 invoked by uid 22791); 22 Nov 2005 11:00:57 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from gateway.sf.frob.com (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Nov 2005 11:00:53 +0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 1E35F357B; Tue, 22 Nov 2005 03:00:51 -0800 (PST) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id BC1C41809B9; Tue, 22 Nov 2005 03:00:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Stone, Joshua I" Cc: Subject: RE: double fault In-Reply-To: Stone, Joshua I's message of Monday, 21 November 2005 19:46:03 -0800 X-Shopping-List: (1) Prosthetic temptations (2) Indigent hatred yies (3) Hard-core melons (4) Absorbent clothes Message-Id: <20051122110050.BC1C41809B9@magilla.sf.frob.com> Date: Tue, 22 Nov 2005 11:00:00 -0000 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00229.txt.bz2 > Shouldn't it be > CONTEXT->regs->esp? Nope. For kernel traps the sp and ss is not saved by the i386 hardware, so that part of the struct pt_regs is not actually there. However, that struct itself is the trap frame of the registers that are pushed on the stack and so it is a stack address near the sp at the time of the fault. > I tried the code you gave (using CONTEXT->regs), but I don't understand > how that computes how much stack space is left. The stacks are 4k and aligned, so & 0xfff is that sp relative to the base of the stack. If sp & 0xfff is very tiny, then the stack is about to overflow. > And even then, you can see the two esp's from the register dumps I gave - > the first would have triggered your panic, and the second wouldn't. The second crash had an esp of 0xf5bd4f98. If that's a proper stack pointer, it's only 104 bytes from the beginning of the stack. Considering that the trap frame itself is 60 bytes, that's fairly small for a realistic stack. It might well be that in fact it's an overflowed stack that grew down from below 0xf5bd6000 and overflowed by getting below 0xf5bd5034 (which is the end of the struct thread_info at the base of the stack). Of course, it's all just speculation that stack overflow is the issue. > Is there a way I can get the double-fault to print a full oops, with a > stack trace? No, it's a special trap handler that uses its own stack and just has the simple printks you've seen. You'd have to do something like put a probe on the line in doublefault_fn where it printk's the esp et al, and have that call show_trace on t->esp or something. Thanks, Roland