From owner-freebsd-hackers  Wed May  7 18:20:45 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA29996
          for hackers-outgoing; Wed, 7 May 1997 18:20:45 -0700 (PDT)
Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA29987
          for <FreeBSD-Hackers@FreeBSD.ORG>; Wed, 7 May 1997 18:20:41 -0700 (PDT)
Received: (qmail 23672 invoked by uid 1000); 8 May 1997 01:04:42 -0000
Message-ID: <XFMail.970507180442.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
In-Reply-To: <199705080030.KAA26380@genesis.atrad.adelaide.edu.au>
Date: Wed, 07 May 1997 17:58:37 -0700 (PDT)
Organization: iConnect Corp.
From: Simon Shapiro <Shimon@i-Connect.Net>
To: Michael Smith <msmith@atrad.adelaide.edu.au>
Subject: Re: Privileged Instruction Fault...
Cc: FreeBSD-SCSI@FreeBSD.ORG, FreeBSD-Hackers@FreeBSD.ORG
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


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