From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27077 invoked by alias); 22 Nov 2005 03:46:20 -0000 Received: (qmail 27071 invoked by uid 22791); 22 Nov 2005 03:46:19 -0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST X-Spam-Check-By: sourceware.org Received: from fmr23.intel.com (HELO scsfmr003.sc.intel.com) (143.183.121.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Nov 2005 03:46:18 +0000 Received: from scsfmr100.sc.intel.com (scsfmr100.sc.intel.com [10.3.253.9]) by scsfmr003.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id jAM3k5D5010650; Tue, 22 Nov 2005 03:46:05 GMT Received: from scsmsxvs041.sc.intel.com (scsmsxvs041.sc.intel.com [10.3.90.10]) by scsfmr100.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id jALKuK7D001196; Mon, 21 Nov 2005 20:56:47 GMT Received: from scsmsx332.amr.corp.intel.com ([10.3.90.6]) by scsmsxvs041.sc.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005112119460404741 ; Mon, 21 Nov 2005 19:46:04 -0800 Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 19:46:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: double fault Date: Tue, 22 Nov 2005 03:46:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: double fault Thread-Index: AcXvA5Qt3Cc0QcpVRPKzCAjDcy2yPgABt0Fg From: "Stone, Joshua I" To: "Roland McGrath" Cc: X-OriginalArrivalTime: 22 Nov 2005 03:46:04.0594 (UTC) FILETIME=[43840920:01C5EF17] X-Scanned-By: MIMEDefang 2.52 on 10.3.253.9 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/msg00227.txt.bz2 >From: Roland McGrath [mailto:roland@redhat.com]=20 > >The stack overflow notion sounds plausible. To investigate=20 >that angle, one >thing to try comes to mind off hand. In each probe that might=20 >be hitting, >stick some %{ ... %} code to do a "stack getting small" check.=20 > It can do >something like: > > unsigned left =3D (unsigned)regs & 0xfff; > if (left < 256) panic("stack getting close"); > >That might manage to print out a full oops with backtrace=20 >details that show >the cascade of page fault frames or whatever the situation actually is. > > >Thanks, >Roland > I tried the code you gave (using CONTEXT->regs), but I don't understand how that computes how much stack space is left. Shouldn't it be CONTEXT->regs->esp? 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. Am I missing something? Anyway, I tried it both ways. It immediately panics, but there's no oops info. It just says "Kernel panic - not syncing". I added a dump_stack call, but that all looks innocent. Is there a way I can get the double-fault to print a full oops, with a stack trace? I'm pretty new to kernel-debugging, so sorry if I'm asking simple questions... Thanks, Josh