From owner-freebsd-current  Sat Jan 23 22:15:13 1999
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA18009
          for freebsd-current-outgoing; Sat, 23 Jan 1999 22:15:13 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18004
          for <current@FreeBSD.ORG>; Sat, 23 Jan 1999 22:15:12 -0800 (PST)
          (envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.2/8.9.1) id WAA60278;
	Sat, 23 Jan 1999 22:14:57 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 23 Jan 1999 22:14:57 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199901240614.WAA60278@apollo.backplane.com>
To: current@FreeBSD.ORG
Subject: Re: panic: found dirty cache page 0xf046f1c0 
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I've committed one bug fix to the 'found dirty cache page' bug --
    turns out vm_map_split() was the culprit, renaming pages
    without removing them from PQ_CACHE.  The bug was introduced
    in -3.0, and hit the KASSERT() I put in -4.x.

    I've committed a general inlining of 'changing the page dirty
    status to VM_PAGE_BITS_ALL' and put a sanity check in the inline.
    If this problem occurs again, you will get a different panic.
    One of:

	vm_page_dirty: page in cache!
	vm_page_busy: page already busy!!!
	vm_page_wakeup: page not busy!!!

    If your box drops into DDB, please get a backtrace and report
    it to the list or to me and we should be able to track down
    any remaining dirty-pages-in-PQ_CACHE bugs.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message