From owner-freebsd-alpha Wed Dec 30 21:14:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20911 for freebsd-alpha-outgoing; Wed, 30 Dec 1998 21:14:09 -0800 (PST) (envelope-from owner-freebsd-alpha@FreeBSD.ORG) Received: from mail.sat.t.u-tokyo.ac.jp (dryad.sat.t.u-tokyo.ac.jp [133.11.156.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20905 for ; Wed, 30 Dec 1998 21:14:08 -0800 (PST) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.156.43]) by mail.sat.t.u-tokyo.ac.jp (8.8.6/3.4Wbeta6-SAT1.0) with ESMTP id OAA09588; Thu, 31 Dec 1998 14:13:47 +0900 (JST) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from localhost by ett.sat.t.u-tokyo.ac.jp (8.8.8/sat-V0.6) id OAA06315; Thu, 31 Dec 1998 14:13:46 +0900 (JST) To: dfr@nlsystems.com Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: panic in pmap_remove_all In-Reply-To: Your message of "Tue, 29 Dec 1998 11:19:35 +0000 (GMT)" References: X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7:#j7i14gu$ jgR\S*&C3R/pJX Date: Thu, 31 Dec 1998 14:13:46 +0900 From: Hidetoshi Shimokawa X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org dfr> > panic: pmap_remove_all: pv_table for 858a000 is inconsistent dfr> > db> trace dfr> > Debugger..ng() at Debugger..ng+0x24 dfr> > panic..ng() at panic..ng+0xf0 dfr> > pmap_remove_all..ng() at pmap_remove_all..ng+0x144 dfr> > pmap_page_protect..ng() at pmap_page_protect..ng+0x2c dfr> > vm_page_cache..ng() at vm_page_cache..ng+0xd4 dfr> > vm_pageout_scan..ng() at vm_pageout_scan..ng+0x3ac dfr> > vm_pageout..ng() at vm_pageout..ng+0x2e0 dfr> > kproc_start..ng() at kproc_start..ng+0x54 dfr> > exception_return() at exception_return dfr> dfr> These bugs are extremely hard to find (it usually involves adding extra dfr> instrumentation to pmap and spending long periods of time in the dfr> debugger). I doubt if I can fix it without being able to reproduce it dfr> locally. Can you give me an idea of what kind of workload triggers the dfr> panic? I was building packages under MFS. The machine has one 9GB disk(1GB for swap) and 512MB memory. All partitions use softupdates. I repeated the following procedure for 'each' port. (mount MFS on /chroot) 1) extract FreeBSD core distribution with tar under /chroot 2) chroot to /chroot and pkg_add dependent packages, then make package. 3) delete all files under /chroot /chroot occupies around 300MB - 600MB. Do you think this is alpha specific problem? /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message