Date: Wed, 07 May 1997 17:58:37 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: FreeBSD-SCSI@FreeBSD.ORG, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Privileged Instruction Fault... Message-ID: <XFMail.970507180442.Shimon@i-Connect.Net> In-Reply-To: <199705080030.KAA26380@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Michael Smith; On 08-May-97 you wrote: > 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. > > And kernel B panics with: > > > > scsi_base.c-567 0xf0ib82a4(0xf088ba80) < This is the printf > > > > > Fatal trap 12: page fault while in kernel mode > > > > Fault address 0x41 > > > > IP = 0x08:0xf01c2f32 > > SP = 0x10:0xefbffce0 > > FP = 0x10:0xefbffd48 > > 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. Thanx, Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970507180442.Shimon>