Date: Thu, 8 May 1997 12:30:47 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Shimon@i-Connect.Net (Simon Shapiro) Cc: msmith@atrad.adelaide.edu.au, FreeBSD-SCSI@FreeBSD.ORG, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Privileged Instruction Fault... Message-ID: <199705080300.MAA27647@genesis.atrad.adelaide.edu.au> In-Reply-To: <XFMail.970507180442.Shimon@i-Connect.Net> from Simon Shapiro at "May 7, 97 05:58:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705080300.MAA27647>