From owner-freebsd-bugs  Thu Jan 16 16:50:04 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA27713
          for bugs-outgoing; Thu, 16 Jan 1997 16:50:04 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA27704;
          Thu, 16 Jan 1997 16:50:02 -0800 (PST)
Date: Thu, 16 Jan 1997 16:50:02 -0800 (PST)
Message-Id: <199701170050.QAA27704@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: kern/2494: page faults
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/2494; it has been noted by GNATS.

From: j@uriah.heep.sax.de (J Wunsch)
To: spatula@gulf.net (Prisoner)
Cc: freebsd-gnats-submit@freefall.freebsd.org
Subject: Re: kern/2494: page faults
Date: Thu, 16 Jan 1997 20:23:43 +0100

 As Prisoner wrote:
 
 >  fault virtual address	= 0x7200c4c
 >  fault code		= supervisor read, page not present
 >  instruction pointer	= 0x8:0xf017c4b4
 >  code segment		= base 0x0, limit 0xfffff, type 0x1b
 >  			= DPL 0, pres 1, def32 1, gran 1
 >  processor eflags	= trace/trap, interrupt enabled, resume, IOPL=0
 >  current process		= 4 (update)
 >  interrupt mask	=
 >  kernel: type 12 trap, code=0
 >  breakpoint at _ffs_update +0xa4:  cmpl  $0x1,0x52c(%ebx)
 >  
 >     It's always within a few instructions to this location.
 
 This is in /sys/ufs/ffs/ffs_inode.c:
 
 int
 ffs_update(ap)
 	struct vop_update_args /* {
 		struct vnode *a_vp;
 		struct timeval *a_access;
 		struct timeval *a_modify;
 		int a_waitfor;
 	} */ *ap;
 {
 ...
 	fs = ip->i_fs;
 	/*
 	 * Ensure that uid and gid are correct. This is a temporary
 	 * fix until fsck has been changed to do the update.
 	 */
 	if (fs->fs_inodefmt < FS_44INODEFMT) {		/* XXX */
 	    ^^^^
 	    here
 
 If it were a genuine bug in the code, it should always happen at the
 same spot, not just `somewhere around'.
 
 The fault VA looks suspicous, it's 0x7200c4c - 0x52c = 0x72000720.
 Somehow, the ip->i_fs pointer has been trashed by dumping the short
 value 0x720 over it.  Incidentally, this value is just a space in the
 video screen buffer, together with the default attribute 0x7 (light
 gray on black).  It looks like part of your screen updates go wild
 into the memory.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)