From owner-freebsd-current Sun Dec 10 16:31:14 2000 From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 16:31:12 2000 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id AF1E837B401 for ; Sun, 10 Dec 2000 16:31:12 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eBB0UdI88063; Sun, 10 Dec 2000 16:30:39 -0800 (PST) (envelope-from dillon) Date: Sun, 10 Dec 2000 16:30:39 -0800 (PST) From: Matt Dillon Message-Id: <200012110030.eBB0UdI88063@earth.backplane.com> To: Philipp Mergenthaler Cc: current@freebsd.org Subject: Re: fix for pageout_flush panic (was Re: panic: vm_pageout_flush: partially dirty page) References: <20001210033546.A13896@rz.uni-karlsruhe.de> <200012102334.eBANYWm87853@earth.backplane.com> <20001211011119.B21036@rz.uni-karlsruhe.de> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I found a second issue... just a normal write-via-mmap issue, which I think INN does. If you mmap() a file fragment and write to it via the mmap(), m->dirty is set to VM_PAGE_BITS_ALL (0xFF). the normal buffer flush will only clear the dirty bits on the page associated with the file fragment, leaving m->dirty 0xFC without an associated buffer. I think *this* is causing the panic. Unfortunately, fixing it properly is a bit delicate because there are cases where it is not appropriate for the buffer cache code to just go and clear m->dirty (e.g. for odd buffer block sizes such as those used for bitmap blocks). I should have a patch in a bit. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message