From owner-freebsd-hackers Wed May 7 20:01:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03904 for hackers-outgoing; Wed, 7 May 1997 20:01:00 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03899; Wed, 7 May 1997 20:00:57 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA27647; Thu, 8 May 1997 12:30:48 +0930 (CST) From: Michael Smith Message-Id: <199705080300.MAA27647@genesis.atrad.adelaide.edu.au> Subject: Re: Privileged Instruction Fault... In-Reply-To: from Simon Shapiro at "May 7, 97 05:58:37 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Thu, 8 May 1997 12:30:47 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, FreeBSD-SCSI@FreeBSD.ORG, FreeBSD-Hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro stands accused of saying: > > > > > > Fata trap 1: Privileged instruction fault while in kernel mode. > > > > > > IP = 0x08:0xf01940c7 > > > SP = 0x10:0xefbffd50 > > > FP = 0x10:0xefbffd68 > > > > Aha, and if you build a kernel and leave all the debugging symbols in, > > as well as DDB, where is the fault? Also check you're not smashing > > your stack. > Ah, but it is, it is. How am I smashing the stack? I know I am, > this is why I posted this help request. But I am not appearing to > be doing anything bad. Well, without looking at the actual code in the function, it's a bit hard to be sure 8) Since "yesterday" when it worked, have you added any local variables to the function? Changed anything at all inside it? Do you use a local buffer? Have you added any more layers to your call stack? Note that the kernel stack is _very_ small; you should not us use automatics of any substantial size. > > Again, check where the IP is in your kernel. Traps with really small > > fault address values are almost always attempts to access structure > > members with a null structure pointer. > Yes, most of us know that. But look again at the source code. We > are not changing any value on either side. Just returning. And the > very nature of the failure changes drastically. It is a panic > alright, but due to totally different reasons. Adding a printf > changes the corruption. I was fishing for clues on this type of > behavior. If there are none, this is also and answer. Printf() uses more stack. I am _guessing_ that you are either running off the end of a local, or using too much stack; it's hard to be sure with so little data and no indication of where the fault IP actually lies within your kernel. > Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[