From owner-freebsd-bugs  Wed Sep 10 08:22:34 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA07533
          for bugs-outgoing; Wed, 10 Sep 1997 08:22:34 -0700 (PDT)
Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA07500;
          Wed, 10 Sep 1997 08:22:15 -0700 (PDT)
Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65])
	by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id RAA20192;
	Wed, 10 Sep 1997 17:21:23 +0200 (MET DST)
Message-Id: <199709101521.RAA20192@pat.idi.ntnu.no>
To: joerg_wunsch@interface-business.de, j@ida.interface-business.de
Cc: bugs@FreeBSD.ORG, dfr@FreeBSD.ORG, dyson@FreeBSD.ORG
Subject: Re: Yet another 2.2-stable NFS (client) panic
In-Reply-To: Your message of "Wed, 10 Sep 1997 12:22:02 +0200"
References: <19970910122202.WS38344@ida.interface-business.de>
X-Mailer: Mew version 1.70 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 10 Sep 1997 17:21:22 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x87654371
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xf013476f
> stack pointer           = 0x10:0xefbffdb0
> frame pointer           = 0x10:0xefbffdc0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 3
> current process         = 7004 (hpscan)
> interrupt mask          = bio 
> 
> 0xf013476f <reassignbuf+147>:   movl   0x50(%edx),%eax
> 
> Register %edx had the fairly suspicious value 0x87654321.  Alas, the
> register values seem to have been clobbered when taking the coredump
> from within DDB.  Here's the stack trace (modulo the frames that were
> caused by the DDB `panic' command, and a subsequent page fault inside
> DDB):

This is the probably the same error as reported in PR#3438
The PR is closed, but the fix is only in 3.0-current, not in 2.2-stable.

- Tor Egge